Modulo Completo Diseño y Administracion

Analista de
Sistemas
materia
Base de Datos
Base de Datos
Programa de la materia
Objetivos Generales de la Asignatura
• Profundizar los conceptos esenciales sobre los sistemas de bases de datos.
• Optimizar y aplicar el modelo relacional en las bases de datos.
• Evaluar y normalizar un conjunto de datos complejos.
• Aprender a desarrollar consultas de base de datos en lenguaje adecuado.
• Aplicar los conocimientos abordados en la instalación, configuración, administración, manejo y resolución de
problemas de motores de base de datos
Unidad Nº 1: Introducción a las bases de datos

OBJETIVOS:
• Aplicar los conceptos asociados a los sistemas de Información computarizados.
• Implementar los conocimientos de los componentes estructurales y los requerimientos de los sistemas de infor-
mación computarizados.
• Desarrollar los criterios sobre la arquitectura y componentes de una base de datos. Interpretar los distintos mode-
los de atracción.
• Aplicar los aspectos funcionales y estructurales del almacenamiento de datos.
CONTENIDOS:
Introducción. Sistemas de Información. Sistemas de Información computarizados. Componentes estructurales
de los sistemas de información computarizados. Requerimientos de los sistemas de información computariza-
dos. Base de Datos. Evolución de los sistemas de Bases de Datos. Primeros Sistemas. Principales características.
Componentes de un sistema. Tipos de base de datos. Arquitectura de la base de datos. Nivel de abstracción.
Manejador de archivos. Metadatos. Diccionario de datos. Almacenamiento físico. Unidades de almacenamiento.
Unidad Nº 2: Sistema gestor de base de datos

OBJETIVOS:
• Desarrollar los conceptos asociados a un sistema gestor de base de datos - SGBD.
• Implementar la iteración de los usuarios con el sistema e interiorizar las estructuras multicapas.
• Desarrollar los criterios sobre el funcionamiento de los sistemas gestores de bases de datos comerciales.
• Aplicar el proceso propuesto por ANSI para de creación y manipulación de una base de datos.
• Aplicar los conceptos de las estructuras operacionales. Conocer situación del Mercado de los SGBD y Estanda-
rización.
• Implementar el proceso de diseño de base de datos mediante los distintos modelos de datos.
CONTENIDOS:
Sistema gestor de base de datos (SGBD). Características deseables. Funciones y Lenguajes. Estructuras multica-
pas. Funcionamiento. Sistema gestor de bases de datos comerciales. Usuarios. Estándar ANSI/SPARC. Proceso de
creación y manipulación de una base de datos propuesta por ANSI. Estructuras operacionales. Características de
una estructura cliente servidor. Situación del Mercado de los SGBD y Estandarización. Diseño de base de datos.
Modelo de datos.
3
Unidad Nº 3: Modelo Entidad Relación
• Desarrollar los conceptos de objetos del modelo entidad relación, así como del modelo entidad relación extendido.
• Aplicar los criterios del diseño de un modelo de Entidad-Relación.
• Implementar los criterios para el modelado Relacional.
• Aplicar el pasaje de modelo entidad/relación a modelo relacional.
• Implementar los conceptos de normalización.
• Aplicar las distintas formas normales.
CONTENIDOS:
Objetos del modelo. Entidad. Relaciones. Atributos. Dominio. Modelo entidad relación extendido. Diseño de un
modelo de Entidad-Relación. Modelo Relacional. Objetivos. Relación o tabla. Claves. Nulos. Restricciones. Las
doce reglas de Codd. Pasaje de modelo entidad/relación a modelo relacional. Normalización. Formas Normales.
Primera forma normal. Segunda forma normal. Tercera forma normal. Forma Normal Boyce-Codd. Cuarta forma
normal. Quinta forma normal.
Unidad Nº 4: SQL, DDL y SML

OBJETIVOS:
• Aplicar los conocimientos del funcionamiento y del proceso de las instrucciones del Lenguaje SQL.
• Desarrollar los criterios de DDL. Modificación. Eliminación. Restricciones.
• Desarrollar los criterios de DML. Instrucciones de control de transacciones. Consultas de datos con SQL-DQL.
Calculo. Condiciones.
• Implementar los modos de autenticar las cuentas de los usuarios.
CONTENIDOS:
Historia del SQL. Funcionamiento. Proceso de las instrucciones. Elementos del Lenguaje SQL. DDL. Modificación.
Eliminación. Restricciones. DML. Instrucciones de control de transacciones. Consultas de datos con SQL-DQL. Cal-
culo. Condiciones. Ejemplos de lo aprendido. Modos de autenticar las cuentas de los usuarios. Usuarios de Base
de Datos.
Analista de Sistemas
Unidad 1
1. Introducción a las bases de datos

2. Sistema gestor de base de datos
3. Modelo Entidad Relación
4. SQL, DDL y SML
Tema Nº 1
Introducción
Cuando nos preguntamos sobre el porqué del uso de computadoras en las empresas, la respuesta parece bas-
tante obvia, para registrar los eventos que se van sucediendo, instanciarlos en el tiempo. Sin embargo existe un
motivo aún más peso y no tan obvio, y es que la información puede usarse para respaldar la toma de decisiones.
Sin importar el tamaño de una empresa u organización, la conducción exitosa de la misma estará altamente in-
fluenciada por la precisión de sus registros y la adopción de decisiones acertadas.
Las comunicaciones y las bases de datos permiten el acceso a recursos de información que están más allá de la
inmediatez física, o las limitaciones geográficas. Las computadoras permiten la utilización de masas de informa-
ción las cuales, no eran concebibles hasta hace algunos años. Pero no sólo basta la disponibilidad de la cantidad
de información, se trata de contar con información de calidad. Los sistemas de información basados en compu-
tadoras no sólo son capaces de suministrarnos información de calidad y oportuna, sino que también pueden
respaldar la toma de decisiones.
¿Qué es un sistema de información?

Primero repasemos algunos conceptos. Recordemos que un sistema es un conjunto de partes o elementos or-
ganizados y relacionados que interactúan entre sí para lograr un objetivo. Mientras que la información es un
conjunto organizado de datos, que constituye un mensaje sobre un cierto fenómeno o ente.
Aclarado lo anterior, los sistemas de información dentro de las organizaciones, no son algo nuevo. Desde mucho
antes de utilizar las computadoras para su automatización, las organizaciones reunían, almacenaban y actua-
lizaban información en el transcurso normal de su actuación diaria. Tanto antes como ahora, los sistemas de
información consistían en procedimientos y reglas establecidas para entregar información a los miembros de la
organización. Cada una de estas personas, requiere información distinta en la realización de su trabajo, las reglas
del sistema indican el tipo, momento, formato y cual es la persona a quien se debería entregar una información
específica.
Impacto de los sistemas de información

La implantación y uso de un sistema de información dentro de una organización regularmente desencadena una
serie de consecuencias, de las cuales unas son positivas y otras no lo son. A continuación, algunas de las ventajas
de contar con un sistema de información y algunos puntos negativos que las organizaciones deben enfrentar al
implantar un sistema de información:
6
Base de Datos
Entre las ventajas de la utilización de un sistema de información computarizado:
• Control más efectivo de las actividades de la organización.

• Integración de las diferentes áreas que conforman la organización.
• Integración de nuevas tecnologías y herramientas de vanguardia.
• Ayuda a incrementar la efectividad en la operación de las empresas.
• Proporciona ventajas competitivas y valor agregado.
• Disponibilidad de mayor y mejor información para los usuarios en tiempo real.
• Elimina la barrera de la distancia trabajando con un mismo sistema en puntos distantes.
• Disminuye errores, tiempo y recursos superfluos. Permite comparar resultados alcanzados
con los objetivos programados, con fines de evaluación y control.
Entre las desventajas se puede encontrar:
• El tiempo que pueda tomar su implementación.

• La resistencia al cambio de los usuarios. Problemas técnicos, si no se hace un estudio adecuado, como fallas
de hardware o de software o funciones implementadas inadecuadamente para apoyar ciertas actividades
de la organización.
Categorías de los sistemas de información

En la medida en que más funciones de las organizaciones se han automatizado, los sistemas de información
se han tornado aceleradamente más especializados, dando origen a distintos sistemas de información. Estos
sistemas individuales podrían llegar a combinarse para convertirse en componentes o subsistemas del sistema
general de información propio de una organización. Los sistemas componen una pirámide, sirviendo de apoyo
esencialmente más no es exclusivo, a uno de los niveles jerárquicos conformados por el personal de la empresa.
En esencia, se tiene en las organizaciones, tres tipos de sistemas de información especializados.

Gráfico 1 – Categorías de los sistemas de información organizacionales.
7
1. Sistema de procesamiento de transacciones: (Registra las operaciones diarias). Estos sistemas permiten a la
organización mejorar y mantener un seguimiento o registro de sus operaciones o transacciones rutinarias, cuyos
datos son almacenadas en una base de datos. Es por esta razón que también se les llama sistemas de procesa-
miento de datos. Los datos de las operaciones son integrados a la base de datos, en la cual se registran las tran-
sacciones de la organización. La base de datos así conformada puede servir de apoyo a los otros tipos de sistemas
de información. Un sistema común de procesamiento de transacciones en todas las empresas es el relacionado
con el área de contabilidad. Entre las actividades que automatiza se encuentra el procesamiento de órdenes de
venta, control de cuentas por cobrar, inventario, cuentas por pagar y nómina.
2. Sistema de información gerencial o administrativa: (Produce reportes estructurados). Es un tipo de sistema

de información que arroja reportes estandarizados en forma breve y estructurada. Apoya la gestión del personal
de rango medio. Se diferencian de los sistemas de procesamiento de transacciones en que los primeros asisten
o mantienen a la base de datos, en tanto que el sistema de información gerencial realmente hace uso de la base
de datos. Puede requerir de administración de la base de datos que integre las bases de datos de los diferentes
departamentos. El personal de nivel medio requiere en general de información resumida originada en distintas
unidades funcionales. Es capaz de producir reportes predeterminados, con un formato previo ya determinado
que presenta siempre el mismo tipo de contenido.
Existen tres categorías comunes de reportes en toda organización. Los reportes periódicos, que se producen a
intervalos de tiempo regulares, por ejemplo, los reportes de ventas mensuales. Los reportes de excepción, que
indican acontecimientos inusuales, por ejemplo, un reporte que muestre que la venta de cierto artículo se en-
cuentre muy por encima de los pronósticos. Los reportes a solicitud, que son realizados por petición expresa, por
ejemplo, cantidad de empleados, de sexo femenino, en un rango determinado de edad; es un reporte que no se
requiere con periodicidad, sino en una situación ocasional, como la evaluación para la contratación de un seguro
médico para los empleados.
3. Sistema de apoyo ejecutivo o soporte de decisiones: (Apoyo al análisis de situaciones imprevistas). Se dife-
rencia de los anteriores, en que es una herramienta flexible de análisis que produce reportes sin formato fijo. Es-
tos sistemas permiten a los gerentes obtener respuestas a problemas inesperados y relativamente excepcionales.
Existen algunas decisiones que no son de naturaleza recurrente y que deben enfrentarse muy ocasionalmente o
incluso una sola vez. Una decisión se considera no estructurada cuando no se cuenta con procedimientos claros,
preestablecidos para adoptarla y no es posible identificar anticipadamente todos los factores a considerar en la
decisión. Un factor clave en el uso de estos sistemas es la flexibilidad de definir la información necesaria. Incluso
ocurre que conforme se adquiere información, el gerente requiera más información, dando un nuevo giro a sus
requerimientos iniciales. Como se percibe, en estos casos, no es posible diseñar previamente ni el formato, ni el
contenido de los reportes del sistema.
Este tipo de sistema debe brindar flexibilidad para que el usuario (gerente o directivo) pueda solicitar informes
definiendo el contenido y la manera de presentar la información. El criterio de los directivos juega un papel im-
portante en la toma de decisiones en problemas no estructurados. Los sistemas que dan soporte, se limitan a
respaldar, pero no reemplazan el criterio del directivo.
Sistemas de información computarizados

Aclarada la función de los sistemas de información dentro de la organización debemos decir que un sistema
manual de información puede llegar a ser ineficiente y frustrante, incluso en organizaciones pequeñas por eso se
tiende a automatizarlo. Un sistema de información automatizado o basado en computadoras, es la integración
de hardware, software, personas, procedimientos y datos. Todos estos elementos se conjugan, trabajando juntos,
para proporcionar información básica para la conducción de la empresa. Esta información hace posible que las
empresas lleven a cabo sus tareas con mayor calidad y facilidad.
Los sistemas de información computarizados, además de llevar un seguimiento de las transacciones y operacio-
nes diarias, propias del negocio, sirven de apoyo al flujo de información interno de la organización. La finalidad
8
Base de Datos
de los sistemas de información organizacionales es, procesar entradas, mantener archivos de datos relacionados
con la organización y producir información, reportes y otras salidas para los usuarios que las necesitan. Puesto
que los sistemas de información dan soporte a los demás sistemas de la organización, los analistas de sistemas
tienen que estudiar primero el sistema organizacional como un todo y así entonces, poder precisar cuáles son y
cómo funcionan los sistemas de información de la organización.
Componentes estructurales de los sistemas de información computarizados

Dichos sistemas de información están compuestos por 6 componentes a saber:
1. Entradas
2. Modelos (procesos)
3. Salidas
4. Tecnología (hardware)
5. Base de datos (almacenamiento)
6. Controles
Entradas
La entrada abarca todos los datos (texto, número, imagen, video, etc.) que entran al sistema de información así
como los métodos y los medios por los cuales se capturan o introducen.
La entrada también esta compuesta por transacciones, solicitudes, consultas, instrucciones, mensajes.
Ejemplos de entradas de datos mediante diferentes medios o captura de los mismos:

Lectura de código de barra, Teclado, Consulta a otro sistema de información.
Las entadas pueden ser de dos tipos:

• Directa: los datos referentes a un evento o transacción se introducen al sistema
en el momento en que ocurren.
• Por lote: las transacciones se acumulan durante algún periodo de tiempo, un día, semana, mes, etc.
Modelos o Procesos
Este componente consta de los modelos lógicos-matemáticos que manipulan de diversas formas, las entradas y
los datos ya almacenados, para producir los resultados deseados o las salidas.
Ejemplo:
Proceso calculo de ganancia:
Ganancia = ingresos - gastos
Salida
La salida es el resultado del proceso este se representa de diferentes maneras.
Resultado = a 1 dato.
Resultado = a un conjunto de datos: como pueden ser los reportes, informes, gráficos estadísticos, cuadros de
resultados, etc.
El resultado o saluda se basa principalmente en su calidad. Cuando hablamos de calidad nos referimos específi-
camente a tres requisitos que debe cumplir dicha salida: exactitud, oportunidad y relevancia.
• Exactitud: el resultado no debe tener desvíos.

• Oportunidad: el resultado debe estar disponible cuando el usuario lo necesite.
• Relevancia: el resultado tiene que ser de importancia para en usuario.
9
Tecnología o hardware
Por definición decimos: corresponde a todas las partes tangibles de una computadora: sus componentes eléc-
tricos, electrónicos, electromecánicos y mecánicos; sus cables, gabinetes o cajas, periféricos de todo tipo y cual-
quier otro elemento físico involucrado.
El hardware es el encargado en conjunto con el software de capturar los datos, procesarlos, almacenarlos, acce-
sarlos, producir salidas y controles de los mismos.
Almacenamiento (Archivos o bases de datos)

Es el lugar donde se contienen los datos necesarios para atender las necesidades de todos los usuarios. Este com-
ponente lo consideraremos desde dos puntos de vista uno físico y otro lógico.
Físico: compuesto por los medios de almacenamiento, discos, cintas, etc.
Lógico: se refiere a la manera que se relacionan los datos entre si.
Controles y seguridad
• Backups de los datos (copias de respaldo).

• Raid de discos.
• Monitoreo de hard y soft.
• Capacitación de usuarios.
• Estructura jerárquica de usuarios.
• Dentro del centro de cómputos ups.
• Sistema contra incendios.
• Accesos restringidos.
Requerimientos de los sistemas de información computarizados

Los requerimientos que deben cumplir de los sistemas de información computarizados los podemos dividir en tres:
1. De sistema
2. Del procesamiento
3. De factibilidad.
Requerimientos de sistemas
1. Confiabilidad: seguridad de que el sistema muestre el resultado esperado.
2. Disponibilidad: cuanto tiempo esta disponible (online).
3. Flexibilidad: que se pueda adaptar a los cambios.
4. Programa de instalación: intervalo de tiempo desde que se pide el sistema y se implementa.
5. Expectativa de vida y potencial crecimiento: el sistema debe satisfacer las necesidades del usuario durante
un tiempo razonable y no tener limitaciones de crecimiento.
Requerimientos de procesamientos de datos

1. Volumen: cantidad de datos que deben procesarse en un periodo dado.
2. Complejidad: cantidad de operaciones y tamaño de las mismas entre datos.
3. Restricciones de tiempo: periodo de tiempo permitido o aceptable entre el momento que se requieren los
datos y el sistema los tiene disponible.
4. Demandas computacionales: es la combinación de volumen, complejidad y restricción de tiempo.
10
Base de Datos
Requerimientos de factibilidad
1. Factibilidad técnica.
2. Factibilidad legal.
3. Factibilidad operacional (que se pueda adiestrar a los usuarios).
4. Factibilidad de programa. (tiempo en que tiene que estar operativo)
Resumen tema 1
Sistema de información: es un conjunto de elementos orientados al tratamiento y administración de datos e in-
formación, organizados y listos para su posterior uso, generados para cubrir una necesidad u objetivo.
Componentes de un Sistema de información computarizado
Operaciones y procedimientos Métodos y los medios

que nos aseguren que por los cuales se
nuestros datos no se pierdan. capturan o introducen
datos.
Modelos lógicos-
matemáticos
Contiene los datos que manipulan
necesarios para las entradas y
atender las los datos ya
necesidades de almacenados,
todos los usuarios. para producir los
resultados.
Es el encargado en
conjunto con el software de
Capturar los datos, procesarlos, Resultado del proceso,
almacenarlos, accesarlos, producir se basa principalmente
salidas y controles de los mismos. en su calidad. Exactitud,
relevancia y oportunidad.
Gráfico 2 – Componentes de un Sistema de información computarizado.
11
Resumen de Requerimientos que deben cumplir de los sistemas de información computarizados.
Sistema Procesamiento Factibilidad
Confiabilidad Volumen Técnica
Disponibilidad Complejidad Legal
Flexibilidad Restricciones de tiempo Operacional
Programa instalación Demandas computacionales De programa
Expectativa de vida
y potencial crecimiento
Cuadro 1 – Requerimientos de un Sistema de información computarizado.
Autoevaluación
1. Defina sistemas de información SI.
2. En un pago con tarjeta de crédito que componentes de un SI intervienen.
3. La agenda de su teléfono celular con que componente de SI se pude identificar análogamente.
4. ¿Por qué cree que es de suma importancia la calidad de una salida o resultado de un proceso?
5. Si estoy pasando una carpeta con música en mi mp3 y me aparece un cartel que no tengo espacio. ¿Qué reque-
rimiento esta no se está cumpliendo en ese proceso de copiado?
6. Me conecto a Internet y quiero leer un diario online, abro el navegador pongo la dirección de la pagina pero no
carga las imágenes y al rato aparece una leyenda que dice expiró el tiempo de conexión con el servidor. ¿Qué
requerimiento esta no se está cumpliendo en ese proceso de cargar la web?
7. ¿Qué entiende por demanda computacional? Conceptualice sus componentes.
8. Le piden que arme un sistema de stock, analiza algunos aspectos como que el sistema se pueda armar, que
existan los instrumentos para llevarlo a cabo, es decir el hardware que pueda soportar dicho sistema. Revisa
que lo que se le esta pidiendo no infrinja la ley, que se licencien las aplicaciones que así lo requieran. Se asegura
que volumen de datos se van almacenar para poder dimensionar la compra de los discos rígidos. ¿Qué se está
analizando?
Investigación
1. Investigue distintos elementos de almacenamiento.
2. Investigue los distintos tipos de sistemas de información.
3. Lea de Diseño de sistemas de Información - Burch J.G., Grudnistki G. Ed. Megabyte. los capítulos:
2 Dimensiones y estructuras.
3 Diseño de los bloques de construcción de los sistemas de información.
12
Base de Datos
Tema Nº 2
Base de datos
Aunque la materia Bases de Datos tiene un carácter propedéutico para la disciplina de los sistemas de bases de
datos y el área más general de sistemas de información, es necesario conocer cuál ha sido la evolución y estado
actual de la tecnología de bases de datos, con el objetivo de estar preparados para los cambios que, inevitable-
mente, se van a dar en el área de las bases de datos y los sistemas de información.
Para ello, en este informe se relata brevemente la evolución de los sistemas de bases de datos, centrándose en
los fundamentos de la tecnología actual y su motivación. Haremos un repaso de las nociones y evolución básicas
de los modelos pre-relacionales, relacionales, objetuales y objeto-relacional, las bases de datos paralelas y distri-
buidas, multimedia, los almacenes de datos, la relación entre las bases de datos y la web, así como otras áreas y
aplicaciones. Esto nos lleva a evaluar la situación actual, especialmente las nuevas demandas sobre sistemas de
información exigidas por el aumento de interconectividad, los nuevos imperativos de publicación e intercambio
de información, los datos semiestructurados y el estándar XML, así como el análisis de datos para la toma de de-
cisión y los avances y perspectivas en las “bases de conocimiento”. Se comentan también las líneas de investiga-
ción abiertas más importantes en el área y una opinión personal sobre hacia donde parece dirigirse la disciplina.
Finalmente, se estudia sucintamente la sociología de la disciplina, su interrelación con otras disciplinas del área
de Lenguajes y Sistemas Informáticos y las organizaciones, congresos y publicaciones más importantes.
Evolución de los Sistemas de Bases de Datos

Los sistemas de información existen desde las primeras civilizaciones. El concepto más esencial de sistema de in-
formación no ha variado desde los censos romanos, por poner un ejemplo. Los datos se recopilaban, se estructu-
raban, se centralizaban y se almacenaban convenientemente. El objetivo inmediato de este proceso era poder re-
cuperar estos mismos datos u otros datos derivados de ellos en cualquier momento, sin necesidad de volverlos a
recopilar, paso que solía ser el más costoso o incluso irrepetible. El objetivo ulterior de un sistema de información,
no obstante, era proporcionar a los usuarios información fidedigna sobre el dominio que representaban, con el
objetivo de tomar decisiones y realizar acciones más pertinentes que las que se realizarían sin dicha información.
Llamamos base de datos justamente a esta colección de datos recopilados y estructurados que existe durante
un periodo de tiempo. Por ejemplo, un libro contable, debido a su estructura, se puede considerar una base de
datos. Una novela, por el contrario, no tiene casi estructura, y no se suele considerar una base de datos.
Generalmente, un sistema de información consta de una o más bases de datos, junto con los medios para alma-
cenarlas y gestionarlas, sus usuarios y sus administradores.
Hoy en día, sin embargo, solemos asociar las bases de datos con los ordenadores, y su gestión no suele ser ma-
nual, sino altamente automatizada. Más concretamente, la tecnología actual insta a la delegación de la gestión de
una base de datos a unos tipos de aplicaciones software específicas denominadas sistemas de gestión de bases
de datos (SGBD) o, simplemente, sistemas de bases de datos. Por esta razón, hablar de la tecnología de bases de
datos es prácticamente lo mismo que hablar de la tecnología de los sistemas de gestión de bases de datos.
Las funciones básicas de un sistema de gestión de base de datos son (Ullman & Widom 1997)
1. Permitir a los usuarios crear nuevas bases de datos y especificar su estructura, utilizando un lenguaje o inter-
faz especializado, llamado lenguaje o interfaz de definición de datos.
2. Dar a los usuarios la posibilidad de consultar los datos (es decir, recuperarlos parcial o totalmente) y modifi-
carlos, utilizando un lenguaje o interfaz apropiado, generalmente llamado lenguaje de consulta o lenguaje
de manipulación de datos.
3. Permitir el almacenamiento de grandes cantidades de datos durante un largo periodo de tiempo, mante-
niéndolos seguros de accidentes o uso no autorizado y permitiendo un acceso eficiente a los datos para
consultas y modificaciones.
4. Controlar el acceso a los datos de muchos usuarios a la vez, impidiendo que las acciones de un usuario pue-
dan afectar a las acciones de otro sobre datos diferentes y que el acceso simultáneo no corrompa los datos.
13
Primeros Sistemas de Base de Datos

Los primeros sistemas de bases de datos aparecieron a finales de los cincuenta. En este periodo, muchas com-
pañías se fueron dando cuenta de que los primeros sistemas informáticos brindaban la posibilidad de aplicar
soluciones mecánicas más baratas y eficientes. Los primeros sistemas evolucionaron de los sistemas de ficheros
que proporcionaban almacenamiento de grandes cantidades de datos durante un largo periodo de tiempo. Sin
embargo, los sistemas de ficheros no garantizaban generalmente que los datos no se perdían ante fallos bastante
triviales, y se basaban casi exclusivamente en recuperación por copia de seguridad.
Además, los sistemas de ficheros proporcionaban de una manera limitada dar a los usuarios la posibilidad de
consultar los datos, es decir, un lenguaje de consultas para los datos en los ficheros. El soporte de estos sistemas
para permitir a los usuarios crear nuevas bases de datos también era limitado y de muy bajo nivel. Finalmente, los
sistemas de ficheros no satisfacen el acceso concurrente a ficheros por parte de varios usuarios o procesos, un sis-
tema de ficheros no previene generalmente las situaciones en la que dos usuarios modifican el mismo fichero al
mismo tiempo, con lo que los cambios realizados por uno de ellos no llegan aparecer definitivamente en el fiche-
ro. Las primeras aplicaciones importantes de los sistemas de ficheros fueron aquellas en la que los datos estaban
compuestos de partes bien diferenciadas y la interrelación entre ellas era reducida. Algunos ejemplos de estas
aplicaciones eran los sistemas de reserva (p.ej. reserva e información de vuelos), los sistemas bancarios donde se
almacenaban las operaciones secuencialmente y luego se procesaban, y los primeros sistemas de organización
corporativos (ventas, facturación, nóminas, etc.).
Los primeros verdaderos SGBDs, evolucionados de los sistemas de ficheros, obligaban a que el usuario visualizara
los datos de manera muy parecida a como se almacenaban. Los primeros sistemas de ficheros habían logrado
pasar del código máquina a un lenguaje ensamblador con ciertas instrucciones de acceso a disco, nociones que
se pueden ver en sistemas todavía en funcionamiento hoy en día, tales como la línea AS de IBM.
No es de extrañar que con este nivel de abstracción la manera de recuperar los datos estaba estrechamente liga-
da al lenguaje de programación utilizado. Un avance importante lo constituyó el comité formado en la COnferen-
ce on DAta SYstems and Languages, CODASYL, en 1960 estableciendo el COmmon Business-Oriented Language
(COBOL) como un lenguaje estándar para interrelacionar con datos almacenados en ficheros. Aunque hoy en día
puede parecer un lenguaje “muy físico”, en aquella época representó lo que se vinieron a llamar los lenguajes de
programación de tercera generación. Las instrucciones específicas de un programa Cobol para tratamiento de
ficheros eran las de abrir un fichero, leer un fichero y añadir un registro a un fichero. Lo típico en gestión de datos
en esta época era un fichero ‘batch’ de transacciones que se aplicaba a un maestro viejo en cinta, produciendo
como resultado un nuevo maestro también en cinta y la impresión para el siguiente día de trabajo.
Pero pronto los discos magnéticos empezaron a sustituir a las cintas magnéticas, lo que supuso una reconcepción
del almacenamiento, al pasarse del acceso secuencial al acceso aleatorio (este paso es el que se conoce como el
paso de los sistemas de bases de datos de primera a segunda generación).
Durante los sesenta empezaron a aparecer distintos modelos de datos para describir la estructura de la informa-
ción en una base de datos, con el objetivo de conseguir una independencia un poco mayor entre las aplicaciones
y la organización física de los datos. Esto se consiguió inicialmente mediante la abstracción entre varios (sub)
esquemas externos para las aplicaciones frente a la organización física de los mismos. Esta separación en dos
niveles fue propuesta por el grupo Data Base Task Group (DBTG) del comité CODASYL.
Los modelos más popularizados fueron el modelo jerárquico o basado en árboles, y el modelo en red o basado en
grafos. Los SGBD acordes con estos modelos se conocieron como SGBD de tercera generación.
Principales características de las bases de datos
1. Independencia lógica y física de los datos.

2. Control centralizado de los datos.
3. Integridad de los datos.
4. Minimización de redundancias.
5. Independencias de los datos y las aplicaciones
6. Acceso concurrente a los datos.
14
Base de Datos
Independencia lógica y física de los datos
Independencia física de los datos

El hardware de almacenamiento y las técnicas físicas de almacenamiento podrán ser modificados sin obligar
a la modificación de los programas de aplicación
Independencia lógica de los datos

Podrán agregarse nuevos ítems de datos, o expandirse la estructura lógica general, sin que sea necesario
reescribir los programas de aplicación existentes, solo se modificara la aplicación que los utiliza.
Control centralizado de los datos

Brinda la posibilidad de control centralizado sobre los recursos de información de una empresa entera u organi-
zación. Antiguamente cada aplicación tiene sus propios archivos privados. La función fundamental del Adminis-
trador de Bases de Datos (DBA) es garantizar la seguridad de los datos; los mismos datos son reconocidos como
un patrimonio de las organizaciones las cuales requieren una responsabilidad centralizada.
Integridad de los datos

Integridad es garantizar que los datos de la base de datos sean exactos. El control centralizado de la base de da-
tos ayuda a evitar la inconsistencia de los datos, por el mismo hecho de encontrarse en un solo lugar y mediante
medidas de seguridad, restricciones y controles para evitar inconsistencias.
Minimización de redundancias
Como distintas aplicaciones se conectan a la base de datos, no hace falta tanta repetición de datos, como en an-
taño que los distintos programas tenían su colección de datos, muchas veces redundados.
Independencias de los datos y las aplicaciones

Se refiere a que podemos quitar un programa que se conecta a la base y cambiarlo por otro sin tener que modi-
ficar la base. Lo mismo a la inversa podemos cambiar la base de datos y debería ser transparente para los progra-
mas que se conectan a ella.
Acceso concurrente a los datos

Diferentes usuarios pueden acceder simultáneamente a la base mediante técnicas de bloqueo o cerrado de datos
accedidos.
Componentes de un sistema de base de datos
• Hardware. Máquinas en las que se almacenan las bases de datos. Incorporan unidades de almacenamiento
masivo para este fin.
• Software. Es el sistema gestor de bases de datos. El encargado de administrar las bases de datos.
• Datos. Incluyen los datos que se necesitan almacenar y los metadatos que son datos que sirven para des-
cribir lo que se almacena en la base de datos.
• Usuarios. Personas que manipulan los datos del sistema. Hay diferentes categorías según sus funciones y
según su grado de uso.
15
Tipos de base de datos
• Bases de datos jerárquicas

• Base de datos de red
• Bases de datos relacionales
• Bases de datos multidimensionales
• Bases de datos orientadas a objetos
Bases de datos jerárquicas

Éstas son bases de datos que, como su nombre indica, almacenan su información en una estructura jerárquica.
En este modelo los datos se organizan en una forma similar a un árbol (visto al revés), en donde un nodo padre
de información puede tener varios hijos. El nodo que no tiene padres es llamado raíz, y a los nodos que no tienen
hijos se los conoce como hojas.
Las bases de datos jerárquicas son especialmente útiles en el caso de aplicaciones que manejan un gran volumen
de información y datos muy compartidos permitiendo crear estructuras estables y de gran rendimiento. Una de las
principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos.
Gráfico 3 – Base de datos jerárquica.
16
Base de Datos
Bases de datos de red

Éste es un modelo ligeramente distinto del jerárquico; su diferencia fundamental es la modificación del concepto
de nodo: se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerárquico).
Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución eficiente al problema de
redundancia de datos; pero, aun así, la dificultad que significa administrar la información en una base de datos de
red ha significado que sea un modelo utilizado en su mayoría por programadores más que por usuarios finales.
Gráfico 4 – Base de datos red.
Base de datos Relacional

Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más
utilizado en la actualidad para implementar bases de datos ya planificadas. Permiten establecer interconexiones
(relaciones) entre los datos (que están guardados en tablas), y a través de dichas conexiones relacionar los datos
de ambas tablas, de ahí proviene su nombre: “Modelo Relacional”.
Características
• Una base de datos relacional se compone de varias tablas o relaciones.

• No pueden existir dos tablas con el mismo nombre ni registro.
• Cada tabla es a su vez un conjunto de registros (filas y columnas).
• La relación entre una tabla padre y un hijo se lleva a cabo por medio de las claves primarias y ajenas (o forá-
neas).
• Las claves primarias son la clave principal de un registro dentro de una tabla y éstas deben cumplir con la
integridad de datos.
• Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave primaria del registro pa-
dre; por medio de éstas se hacen las relaciones.
17

Gráfico 5 – Base de datos relacional.
Bases de datos multidimensionales
Visualización de los datos mediante un cubo

La vista de los datos como un cubo es una extensión natural de como la mayoría de los usuarios de negocios
interactúan con los datos.
Ellos ven a un problema de negocios en términos de un cierto número de componentes (dimensiones) tales
como productos, tiempo, regiones, fabricantes, o artículos.
Los usuarios de negocios desean poder analizar un conjunto de números usando cualquier par de estos
componentes, como así también poder intercambiarlos para lograr distintas vistas.
Ejemplo ventas de productos en diferentes regiones:
Gráfico 6 – Base de datos multidimensional – Tabla región.
18
Base de Datos
Para un mayor análisis se desearía ver cómo se desarrollan las ventas por producto en un periodo dato. Para hacer
esto, se necesitarían abrir varias tablas simultáneamente.
Gráfico 7 – Base de datos multidimensional – Tabla región en el tiempo.
Esto mismo en un cubo lo tratamos como dimensiones una seria la de tiempo, otra de productos y una última
región.
Gráfico 8 – Base de datos multidimensional – Dimensiones región y tiempo.
19
Dado que las agrupaciones de datos pueden ser fácilmente representadas en un cubo, a la hora de usarla son
mucho más rápidas que las relacionales. Si bien llevan más diseño, a la hora de usarlas me evita muchos cruces
de datos, que ya los pensé y aplique en el diseño. Por ejemplo si quiero saber:
• ¿Cómo se venden los productos en cada región en un mes dado? Esto es equivalente a ver Producto por
Región en un mes dado.
• ¿Qué regiones han mejorado las ventas de un producto dado a través del tiempo? Esto es equivalente a
Región por Tiempo de un producto dado.
• ¿Cómo se venden los productos a través del tiempo en una región dada? Esto es equivalente a Producto por
Tiempo en una región dada.
Bases de datos orientadas a objetos

En una base de datos orientada a objetos, la información se representa mediante objetos como los presentes en
la programación orientada a objetos.
Las bases de datos orientadas a objetos se diseñan para trabajar bien en conjunción con lenguajes de progra-
mación orientados a objetos. Dichos objetos se extienden en los lenguajes como datos persistentes de forma
transparente, control de concurrencia, recuperación de datos, consultas asociativas y otras capacidades.
Gráfico 9 – Base de datos

orientada a objeto.
20
Base de Datos
Alguien podría pensar, por tanto, que las bases de datos orientadas a objetos deberían de haber superado en la
práctica a las relacionales. De hecho, a veces se denominan postrelacionales. No obstante, después de más 15
años, el mercado de las bases de datos orientadas a objetos no supone más de un 5% del mercado de las relacio-
nales, como se puede ver en las siguientes gráficas:
Gráfico 10 – Ingresos de las ventas mundiales

de SGBD (millones de dólares.)
entre 1999 y 2000, y predicciones 2001-2004.
Fuente: IDG 2000 (tomado de [Leavitt 2000])
Resumen tema 2
Una base de datos puede definirse como una colección de datos (objetos) interrelacionados almacenados en
conjunto sin redundancias perjudiciales o innecesarias; su finalidad es la de servir a una aplicación o más, de
la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que
los usan; se emplean métodos bien determinados para incluir datos nuevos y para modificar o extraer los datos
almacenados.
Principales características de las bases de datos.
1. Independencia lógica y física de los datos.

2. Control centralizado de los datos.
3. Integridad de los datos.
4. Minimización de redundancias.
5. Independencias de los datos y las aplicaciones
6. Acceso concurrente a los datos.
21
Componentes de un sistema de base de datos:
1. Hardware
2. Software.
3. Datos.
4. Usuarios.
Tipos de base de datos
1. Bases de datos jerárquicas

2. Base de datos de red
3. Bases de datos relacionales
4. Bases de datos multidimensionales
5. Bases de datos orientadas a objetos
Autoevaluación
1. ¿Para qué sirve una base de datos en una organización?
2. ¿A qué se refiere la independencia lógica y física de los datos?
3. El control centralizado de los datos es una de las características de la base de datos. ¿Cuales otras características
son posibles gracias al control centralizado?
4. Analicemos esta situación: Tengo mi curriculum que lo hice hace un tiempo en office 2003 después de unos
años cambio el office por el 2007, puedo decir que cambio de aplicación, mientras que mi curriculum es el dato
sigue siendo el mismo. Si hacemos una analogía de esta situación con una base de datos. ¿Que característica
de las bases de datos se pone en manifiesto?
5. De los componentes de la base de datos, los usuarios ¿en función de que se clasifican?
6. ¿En qué se diferencia una base de datos jerárquica y una de red?
7. ¿En qué se diferencia una base de datos relacional y una multidimencional?
8. ¿Para qué me sirve una base de datos orientada a objetos?
Investigación
1. Investigue hoy en día que tipo de base de datos es la más usada.
2. Indague sobre bases de datos jerárquicas y de red.
3. Lea de Introducción a la informática – Mario D Albarracín, Eduardo A Lancharro, Miguel García López. el capítu-
lo 7 Archivos y base de datos.
4. Lea de Organización de base de datos – James Martin. los capítulos: 3 ¿Qué es una base de datos? Y 4 ¿Cuáles
deberían ser los objetivos de una organización de base de datos?
22
Base de Datos
Tema Nº 3
Arquitectura de la base de datos
Como antes de la aparición de las bases de datos, los registros se encontraban organizados especialmente para
unas aplicaciones determinadas, al estar almacenados en sus propias cintas o paquetes de discos, de forma que
los datos de operación se hallan muy dispersos y eran difíciles de controlar, incluso que los programas para acce-
der a esos datos estaban muchas veces escritos en lenguajes diferentes, surgió la necesidad de una Base de Datos
es que esos registros puedan ser utilizados por tantas aplicaciones como sea posible; para ello se han de integrar
los archivos de datos, eliminándose parcial o totalmente la redundancia entre ellos.
A pesar de estar definidas las bases de datos como una colección no redundante de datos hay ocasiones en que
las bases de datos soportan o admiten una cierta redundancia con el objeto de reducir los tiempos de acceso o
simplificar los métodos de direccionamiento, hablándose, en este caso, de una redundancia controlada o mínima.
Por este motivo hay quienes ven a la Base de Datos como un enorme receptáculo donde se reúne toda la infor-
mación necesaria para el ejercicio de las funciones propias de una empresa.
Cuando un conjunto de datos sirve a una variedad de programas de aplicaciones, cada uno de los programas per-
cibe relaciones diferentes entre los datos. En estas condiciones el secreto y la seguridad de los datos, así como la
posibilidad de reconstruirlos en caso de algún error, son aspectos importantes en el diseño de las bases de datos.
Antes de que surgieran las computadoras de la tercera generación, la primera fue instalada en 1965. Los archivos
estaban organizados en forma secuencial y el software ejecutaba las operaciones de E/S de los dispositivos de
almacenamiento y pocas cosas más. La codificación incluida en los programas era la responsable de la organiza-
ción de los datos y no había independencia entre ellos: si se cambiaba el dispositivo de almacenamiento o la or-
ganización, el programador se veía obligado a escribir un nuevo programa. La mayor parte de los archivos servían
sólo para una aplicación. Para poder ser utilizados en otras aplicaciones debían estar organizados de otra forma y
con campos diferentes, lo que llevaba consigo un alto grado de redundancia entre los archivos.
La llegada de los dispositivos de direccionamiento directo permitió al usuario el acceso a un determinado regis-
tro sin tener que pasar por los demás, pero era tarea del programador el especificar el tipo de direccionamiento
utilizado.
Al reconocerse la naturaleza cambiante de los archivos y del dispositivo de almacenamiento, el software permitió
modificar la distribución física de los datos sin tener que alterar la estructura lógica. Los archivos seguían estando
diseñados para una aplicación determinada o para un grupo de aplicaciones muy similares. Cualquier nueva ne-
cesidad de la empresa obligaba a crear nuevos archivos y, por tanto, nuevos programas.
La evolución del procesamiento de los datos comerciales llevó a independizar los programas de aplicaciones no
sólo de los cambios del hardware y del aumento del volumen de los datos, sino también de la adición de nuevos
campos a la estructura lógica del archivo.
Si se pretende agregar nuevos campos a los registros, sin alterar los programas de aplicación, es necesario que
el software se refiera a los datos a nivel de campo, en lugar de hacerlo a nivel de registro. Para un programador,
un registro puede estar constituido por una serie de campos, y otro programador puede tener otra visión lógica
completamente distinta de ese registro.
En 1975 ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee)
propone una arquitectura de sistemas de bases de datos de tres esquemas o niveles de abstracción como ayuda
para conseguir la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por par-
te de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos.
Niveles de abstracción de una base de datos

En cualquier sistema de información se considera que se pueden observar los datos desde dos puntos de vista:
• Vista externa: Esta es la visión de los datos que poseen los usuarios del Sistema de Información.
• Vista física: Esta es la forma en la que realmente están almacenados los datos.
23
En un sistema orientado a procesos, los usuarios ven los datos desde las aplicaciones creadas por los programa-
dores. Esa vista pueden ser formularios, informes visuales o en papel... Pero la realidad física de esos datos, tal cual
se almacenan en los discos queda oculta. Esa visión está reservada a los administradores.
En el caso de los Sistemas de Base de datos, se añade una tercera vista, que es la vista conceptual. Esa vista se sitúa en-
tre la física y la externa. Se habla pues en Bases de datos de la utilización de tres esquemas para representar los datos.
Esquema físico
Esquema físico o nivel interno es la representación inferior de una Base de Datos, por ello es el más cercano al
almacenamiento físico.
Permite describir los datos tal como están almacenados en la computadora; por ejemplo:
Los archivos que los contienen (nombre, organización, ubicación...).
Los registros de estos archivos (longitud, campos...).
Las rutas de acceso a esos registros (índices, encadenamientos, archivos invertidos...)
Este es el nivel más bajo de abstracción de la información.
Esta visión sólo la requiere el administrador/a. El administrador la necesita para poder gestionar más eficiente-
mente la base de datos.
Esquema Conceptual
Se trata de un esquema teórico de los datos en el que figuran organizados en estructuras reconocibles del mundo
real y en el que también aparece la forma de relacionarse los datos. Este esquema es el paso que permite modelar
un problema real a su forma correspondiente en la base. Este esquema es la base de datos de todos los demás.
Como se verá más adelante es el primer paso a realizar al crear una base de datos.
El esquema conceptual lo realiza diseñadores/as o analistas.
Dicho de otra manera este nivel corresponde a la estructura organizacional de los datos de la base obtenida al
reunir los requerimientos de todos los usuarios de una empresa, sin preocuparse de su organización física ni las
vías de acceso.
Esquema o nivel externo

Se trata de la visión de los datos que poseen los usuarios y usuarias finales. Esa visión es la que obtienen a través de las
aplicaciones. Las aplicaciones creadas por los desarrolladores abstraen la realidad conceptual de modo que el usuario
no conoce las relaciones entre los datos, como tampoco conoce todos los datos que realmente se almacenan.
Realmente cada aplicación produce un esquema externo diferente (aunque algunos pueden coincidir) o vista de
usuario. El conjunto de todas las vistas de usuario es lo que se denomina esquema externo global.
Gráfico 11
Niveles de abstracción
de la base de datos.
24
Base de Datos
Manejador de archivo
Los medios para obtener y analizar esos datos, para extraerlos, transformarlos y cargarlos, así como las diferentes
formas para realizar la gestión de datos son componentes esenciales de un almacén de datos
En esta definición se incluyen herramientas para la inteligencia empresarial, herramientas para extraer, transfor-
mar y cargar datos en el almacén de datos, y herramientas para gestionar y recuperar los metadatos.
Metadatos
Uno de los componentes más importantes de la arquitectura de un almacén de datos son los metadatos. Se defi-
ne comúnmente como “datos acerca de los datos”, en el sentido de que se trata de datos que describen cuál es la
estructura de los datos que se van a almacenar y cómo se relacionan.
El metadato documenta internamente, entre otras cosas, qué tablas existen en una base de datos, qué columnas
posee cada una de las tablas y qué tipo de datos se pueden almacenar. Así como los permisos, relaciones, restric-
ciones, todo lo referente a la estructura de la base.
Diccionario de datos
Es un listado organizado de todos los elementos de datos pertinentes al sistema, con definiciones precisas y rigu-
rosas para que el usuario y el analista de sistemas puedan conocer todas las entradas, salidas, componentes de
depósitos y cálculos intermediarios. (no confundir con metadata, si bien va ser lo mismo a efectos descriptivos de
la base, la metadata la lee y entiende el SGDB y el diccionario de datos el humano).
Almacenamiento físico de bases de datos

La mayoría de las bases de datos se almacenan en las llamadas memorias secundarias, especialmente discos du-
ros, aunque, en principio, pueden emplearse también discos ópticos, memorias flash, etc.
Las razones por las cuales las bases de datos se almacenan en memorias secundarias son:
• En general, las bases de datos son demasiado grandes para entrar en la memoria primaria.
• La memoria secundaria suele ser más barata que la memoria primaria (aunque esta última tiene mayor
velocidad).
• La memoria secundaria es más útil para el almacenamiento de datos permanente, puesto que la memoria
primaria es volátil.
En cuanto al respaldo de las bases de datos (ver backup), suelen emplearse tanto discos duros, como cintas mag-
néticas, discos ópticos o similares.
Técnicas de almacenamiento y recuperación de bases de datos

Las técnicas empleadas para almacenar bases de datos son sumamente importantes para la velocidad de acceso
y recuperación de datos. Las técnicas dependen del tipo de almacenamiento, el uso que se le da o se le dará a
la base de datos, la estructura de la misma, SGBD gestor o manejador de la base de datos empleado (se vera en
detalle en el modulo siguiente), etc.
Esta dependencia no significa necesariamente que haya que cambiar la estructura de la base de datos si se cam-
bian las técnicas empleadas. Las técnicas de almacenamiento son independientes de la base de datos, pero, de
todas maneras, las mejores técnicas muchas veces pueden determinarse viendo la estructura de la base de datos,
entre otras características.
Los encargados de elegir estas técnicas son los diseñadores y administradores de bases de datos, y dependen tam-
bién de las capacidades del SGBD. En general, el SGBD ofrece diferentes opciones y técnicas para organizar los datos.
La idea es que los encargados de la base de datos encuentren las técnicas idóneas, o sea, aquellas que permitan
la mayor velocidad posible de acceso a los datos. Una mala decisión en esta área puede resultar en una menor
velocidad de acceso a la base de datos, o en un uso excesivo del espacio de almacenamiento, o incluso, puede au-
mentar la velocidad de consulta de una base de datos, pero disminuir la velocidad de actualización de la misma.
25
El almacenamiento en archivos de las bases de datos

Las bases de datos se almacenan en ficheros o archivos. Existen diferentes formas de organizaciones primarias
de archivos que determinan la forma en que los registros de un archivo se colocan físicamente en el disco y, por
lo tanto, cómo se accede a éstos.
Las distintas formas de organizaciones primarias de archivos son:
• Archivos de montículos (o no ordenados): esta técnica coloca los registros en el disco sin un orden específi-
co, añadiendo nuevos registros al final del archivo.
• Archivos ordenados (o secuenciales): mantiene el orden de los registros con respecto a algún valor de algún
campo (clave de ordenación).
• Archivos de direccionamiento calculado: utilizan una función de direccionamiento calculado aplicada a un

campo específico para determinar la colocación de los registros en disco.
• Árboles B: se vale de la estructura de árbol para las colocaciones de registros.
Existe una segunda forma de acceder a los datos llamada organización secundaria o estructura de acceso auxiliar.
Estas permiten que los accesos a los registros de un archivo basado en campos alternativos, sean más eficientes
que los que han sido utilizados para la organización primaria de archivos.
Unidades de almacenamientos - Discos Rígidos

En informática, un disco duro o disco rígido (en inglés Hard Disk Drive, HDD) es un dispositivo de almacenamien-
to de datos no volátil que emplea un sistema de grabación magnética para almacenar datos digitales. Se compo-
ne de uno o más platos o discos rígidos, unidos por un mismo eje que gira a gran velocidad dentro de una caja
metálica sellada. Sobre cada plato, y en cada una de sus caras, se sitúa un cabezal de lectura/escritura que flota
sobre una delgada lámina de aire generada por la rotación de los discos.
El primer disco duro fue inventado por IBM en 1956. A lo largo de los años, los discos duros han disminuido su
precio al mismo tiempo que han multiplicado su capacidad, siendo la principal opción de almacenamiento se-
cundario para PC desde su aparición en los años 60.1 Los discos duros han mantenido su posición dominante
gracias a los constantes incrementos en la densidad de grabación, que se ha mantenido a la par de las necesida-
des de almacenamiento secundario.
Los tamaños también han variado mucho, desde los primeros discos IBM hasta los formatos estandarizados ac-
tualmente: 3,5” los modelos para PC y servidores, 2,5” los modelos para dispositivos portátiles. Todos se comu-
nican con la computadora a través del controlador de disco, empleando una interfaz estandarizado. Los más
comunes hoy día son IDE (también llamado ATA o PATA), SCSI (generalmente usado en servidores y estaciones de
trabajo), Serial ATA y FC (empleado exclusivamente en servidores).
Para poder utilizar un disco duro, un sistema operativo debe aplicar un formato de bajo nivel que defina una o
más particiones. La operación de formateo requiere el uso de una fracción del espacio disponible en el disco, que
dependerá del formato empleado. Además, los fabricantes de discos duros, SSD y tarjetas flash miden la capaci-
dad de los mismos usando prefijos SI, que emplean múltiplos de potencias de 1000 según la normativa IEC, en
lugar de los prefijos binarios clásicos de la IEEE, que emplean múltiplos de potencias de 1024, y son los usados
mayoritariamente por los sistemas operativos. Esto provoca que en algunos sistemas operativos sea representa-
do como múltiplos 1024 o como 1000, y por tanto existan ligeros errores, por ejemplo un Disco duro de 500 GB,
en algunos sistemas operativos sea representado como 465 GiB (Según la IEC Gibibyte, o Gigabyte binario, que
son 1024 Mebibytes) y en otros como 465 GB.
26
Base de Datos
Estructura física
Dentro de un disco duro hay uno o varios discos (de aluminio o cristal) concéntricos llamados platos (normalmen-
te entre 2 y 4, aunque pueden ser hasta 6 ó 7 según el modelo), y que giran todos a la vez sobre el mismo eje, al
que están unidos. El cabezal (dispositivo de lectura y escritura) está formado por un conjunto de brazos paralelos
a los platos, alineados verticalmente y que también se desplazan de forma simultánea, en cuya punta están las
cabezas de lectura/escritura. Por norma general hay una cabeza de lectura/escritura para cada superficie de cada
plato. Los cabezales pueden moverse hacia el interior o el exterior de los platos, lo cual combinado con la rotación
de los mismos permite que los cabezales puedan alcanzar cualquier posición de la superficie de los platos.
Cada plato posee dos caras, y es necesaria una cabeza de lectura/escritura para cada cara. Posee una estructura
Cilindro-Cabeza-Sector de más abajo, a primera vista se ven 4 brazos, uno para cada plato. En realidad, cada uno
de los brazos es doble, y contiene 2 cabezas: una para leer la cara superior del plato, y otra para leer la cara inferior.
Por tanto, hay 8 cabezas para leer 4 platos, aunque por cuestiones comerciales, no siempre se usan todas las caras
de los discos y existen discos duros con un número impar de cabezas, o con cabezas deshabilitadas. Las cabezas
de lectura/escritura nunca tocan el disco, sino que pasan muy cerca (hasta a 3 nanómetros), debido a una finísima
película de aire que se forma entre éstas y los platos cuando éstos giran (algunos discos incluyen un sistema que
impide que los cabezales pasen por encima de los platos hasta que alcancen una velocidad de giro que garantice
la formación de esta película). Si alguna de las cabezas llega a tocar una superficie de un plato, causaría muchos
daños en él, rayándolo gravemente, debido a lo rápido que giran los platos (uno de 7.200 revoluciones por minu-
to se mueve a 129 km/h en el borde de un disco de 3,5 pulgadas).
Direccionamiento
Hay varios conceptos para referirse a zonas del disco:
1. Plato: cada uno de los discos que hay dentro del disco duro.
2. Cara: cada uno de los dos lados de un plato.
3. Cabeza: número de cabezales.
4. Pistas: una circunferencia dentro de una cara; la pista 0 está en el borde exterior.
5. Cilindro: conjunto de varias pistas; son todas las circunferencias que están alineadas verticalmente (una de
cada cara).
Sector: cada una de las divisiones de una pista. El tamaño del sector no es fijo, siendo el estándar actual 512 bytes,
aunque próximamente serán 4 KiB. Antiguamente el número de sectores por pista era fijo, lo cual desaprove-
chaba el espacio significativamente, ya que en las pistas exteriores pueden almacenarse más sectores que en las
interiores. Así, apareció la tecnología ZBR (grabación de bits por zonas) que aumenta el número de sectores en
las pistas exteriores, y utiliza más eficientemente el disco duro.
El primer sistema de direccionamiento que se usó fue el CHS (cilindro-cabeza-sector), ya que con estos tres va-
lores se puede situar un dato cualquiera del disco. Más adelante se creó otro sistema más sencillo: LBA (direccio-
namiento lógico de bloques), que consiste en dividir el disco entero en sectores y asignar a cada uno un único
número. Éste es el que actualmente se usa.
27
Tipos de conexión
Si hablamos de disco duro podemos citar los distintos tipos de conexión que poseen los mismos con la placa
base, es decir pueden ser SATA, IDE, SCSI o SAS:
1. IDE: Integrated Device Electronics (“Dispositivo electrónico integrado”) o ATA (Advanced Technology Atta-
chment), controla los dispositivos de almacenamiento masivo de datos, como los discos duros y ATAPI (Ad-
vanced Technology Attachment Packet Interface) Hasta aproximadamente el 2004, el estándar principal
por su versatilidad y asequibilidad. Son planos, anchos y alargados.
2. SCSI: Son interfaces preparadas para discos duros de gran capacidad de almacenamiento y velocidad de
rotación. Se presentan bajo tres especificaciones: SCSI Estándar (Standard SCSI), SCSI Rápido (Fast SCSI) y
SCSI Ancho-Rápido (Fast-Wide SCSI). Su tiempo medio de acceso puede llegar a 7 milisegundos y su ve-
locidad de transmisión secuencial de información puede alcanzar teóricamente los 5 Mbps en los discos
SCSI Estándares, los 10 Mbps en los discos SCSI Rápidos y los 20 Mbps en los discos SCSI Anchos-Rápidos
(SCSI-2). Un controlador SCSI puede manejar hasta 7 discos duros SCSI (o 7 periféricos SCSI) con conexión
tipo margarita (daisy-chain). A diferencia de los discos IDE, pueden trabajar asincrónicamente con relación
al microprocesador, lo que posibilita una mayor velocidad de transferencia.
3. SATA (Serial ATA): El más novedoso de los estándares de conexión, utiliza un bus serie para la transmisión
de datos. Notablemente más rápido y eficiente que IDE. Existen tres versiones, SATA 1 con velocidad de
transferencia de hasta 150 MB/s (hoy día descatalogado), SATA 2 de hasta 300 MB/s, el más extendido en la
actualidad; y por último SATA 3 de hasta 600 MB/s el cual se está empezando a hacer hueco en el mercado.
Físicamente es mucho más pequeño y cómodo que los IDE, además de permitir conexión en caliente.
4. SAS (Serial Attached SCSI): Interfaz de transferencia de datos en serie, sucesor del SCSI paralelo, aunque
sigue utilizando comandos SCSI para interaccionar con los dispositivos SAS. Aumenta la velocidad y permite
la conexión y desconexión en caliente. Una de las principales características es que aumenta la velocidad de
transferencia al aumentar el número de dispositivos conectados, es decir, puede gestionar una tasa de trans-
ferencia constante para cada dispositivo conectado, además de terminar con la limitación de 16 dispositivos
existente en SCSI, es por ello que se vaticina que la tecnología SAS irá reemplazando a su predecesora SCSI.
Además, el conector es el mismo que en la interfaz SATA y permite utilizar estos discos duros, para aplicacio-
nes con menos necesidad de velocidad, ahorrando costes. Por lo tanto, las unidades SATA pueden ser utiliza-
das por controladoras SAS pero no a la inversa, una controladora SATA no reconoce discos SAS.
Resumen Tema 3
Arquitectura ANSI
La arquitectura de sistemas de bases de datos de tres esquemas fue aprobado por la ANSI-SPARC ayuda para
conseguir la separación entre los programas de aplicación y los datos.
• Nivel interno: Tiene un esquema interno que describe la estructura física de almacenamiento de base de
datos. Emplea un modelo físico de datos y los únicos datos que existen están realmente en este nivel.
• Nivel conceptual: tiene esquema conceptual. Describe la estructura de toda la base de datos para una co-
munidad de usuarios. Oculta los detalles físicos de almacenamiento y trabaja con elementos lógicos como
entidades, atributos y relaciones.
• Nivel externo o de vistas: tiene varios esquemas externos o vistas de usuario. Cada esquema describe la
visión que tiene de la base de datos a un grupo de usuarios, ocultando el resto.
El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicación de la base de datos física.
Manejador de archivo: Los medios para obtener y analizar esos datos, para extraerlos, transformarlos y cargarlos.
Metadatos: describen cuál es la estructura de los datos que se van a almacenar y cómo se relacionan.
28
Base de Datos
Diccionario de datos: Es un listado organizado de todos los elementos de datos pertinentes al sistema.
Almacenamiento de la base de datos

Las técnicas empleadas para almacenar bases de datos son sumamente importantes para la velocidad de acceso
y recuperación de datos. Las técnicas dependen del tipo de almacenamiento, el uso que se le da o se le dará a la
base de datos, la estructura de la misma, SGBD empleado entre otras.
Distintas formas de organizaciones primarias de archivos:
• Archivos de montículos (o no ordenados): esta técnica coloca los registros en el disco sin un orden específi-
co, añadiendo nuevos registros al final del archivo.
• Archivos ordenados (o secuenciales): mantiene el orden de los registros con respecto a algún valor de algún
campo (clave de ordenación).
• Archivos de direccionamiento calculado: utilizan una función de direccionamiento calculado aplicada a un
campo específico para determinar la colocación de los registros en disco.
• Árboles B: se vale de la estructura de árbol para las colocaciones de registros.
Unidad de almacenamiento – Disco Rígido.

En informática, un disco duro o disco rígido (en inglés Hard Disk Drive, HDD) es un dispositivo de almacenamien-
to de datos no volátil que emplea un sistema de grabación magnética para almacenar datos digitales. Se compo-
ne de uno o más platos o discos rígidos, unidos por un mismo eje que gira a gran velocidad dentro de una caja
metálica sellada. Sobre cada plato, y en cada una de sus caras, se sitúa un cabezal de lectura/escritura que flota
sobre una delgada lámina de aire generada por la rotación de los discos.
Estructura física
Dentro de un disco duro hay uno o varios discos o platos que giran todos a la vez sobre el mismo eje, al que están
unidos. Un cabezal (lectura y escritura) está formado por un conjunto de brazos paralelos a los platos, alineados
verticalmente y que también se desplazan de forma simultánea, en cuya punta están las cabezas de lectura/escri-
tura. Por norma general hay una cabeza para cada superficie de cada plato. Cada plato posee dos caras.
Tipo de conexión: si hablamos de disco duro podemos citar los distintos tipos de conexión que poseen los mis-
mos con la placa base, es decir pueden ser SATA, IDE, SCSI o SAS.
Autoevaluación
1. ¿Qué propuso ANSI-SPARC?
2. ¿Cuál es la finalidad?
3. ¿Que entiende por Nivel interno?
4. ¿Qué entiende por Nivel conceptual?
5. ¿Qué entiende por Nivel físico?
6. Si hago un backup y restore de la estructura de la base no se hace un backup de los datos sino que de la estruc-
tura. ¿Qué es lo que se está copiando el diccionario de datos o la metadata?
7. ¿Qué hace específicamente el manejador de archivo de la base de datos?
8. El administrador de base de datos tiene documentada la estructura de datos en qué lugar.
29
Investigación
1. Profundice sobre la arquitectura de base de datos.
2. El sitio de Microsoft indague sobre el Diccionario de datos de AdventureWorks la base de estudio de MS.
3. Sondee en el mercado que tipos de discos se ofrecen y con prestaciones. Analice las diferencias principales.
4. Lea de Sistemas de base de datos – conceptos fundamentales – Elmasri - Navathe. Pearson educación.
Capítulo 2 Concepto y arquitectura de los sistemas de base de datos.
Capítulo 3 Modelado de datos con el enfoque entidad vínculo.
5. Lea de Sistemas de base de datos – C.J. Date – Addison-Wesley Iberoamericana. Capitulo 2 Una arquitectura
para sistemas de base de datos.
30
Unidad 2

4. SQL, DDL y SML
Tema Nº 4
Sistema gestor de base de datos
Un sistema gestor de bases de datos o SGBD (aunque se suele utilizar más a menudo las siglas DBMS procedentes
del inglés, Data Base Management System) es el software que permite a los usuarios procesar, describir, adminis-
trar y recuperar los datos almacenados en una base de datos.
En estos Sistemas se proporciona un conjunto coordinado de programas, procedimientos y lenguajes que per-
miten a los distintos usuarios realizar sus tareas habituales con los datos, garantizando además la seguridad de
los mismos.
El éxito del SGBD reside en mantener la seguridad e integridad de los datos. Lógicamente tiene que proporcionar
herramientas a los distintos usuarios. Entre las herramientas que proporciona están:
• Herramientas para la creación y especificación de los datos. Así como la estructura de la base de datos.
• Herramientas para administrar y crear la estructura física requerida en las unidades de almacenamiento.
• Herramientas para la manipulación de los datos de las bases de datos, para añadir, modificar, suprimir o
consultar datos.
• Herramientas de recuperación en caso de desastre.
• Herramientas para la creación de copias de seguridad.
Gráfico 12 - Gestor de base

de datos SGDB o MBMS.

• Herramientas para la gestión de la comunicación de la base de datos.
• Herramientas para la creación de aplicaciones que utilicen esquemas externos de los datos.
• Herramientas de instalación de la base de datos
• Herramientas para la exportación e importación de datos
Características deseables en un SGBD

1. Control de redundancia.
2. Restricción de accesos no autorizados.
3. Almacenamiento de objetos y estructuras de datos de programas.
4. Inferencias en la BD mediante reglas de deducción.
5. Suministro múltiple de interfaces con los usuarios.
6. Recuperación de vínculos complejos entre los datos.
7. Cumplimiento de las restricciones de integridad.
8. Respaldo y recuperación.
32
Base de Datos
Control de redundancia
El SGBD consta de herramienta para crear restricciones para evitar duplicaciones.
Restricción de accesos no autorizados

Tenemos muchos usuarios que comparten la base pero no todos deben tener acceso a toda la información que
ella contiene. El SGBD debe contar con un subsistema de seguridad y autorización que permita al DBA adminis-
trar restricciones y autorizaciones.
Inferencias en la BD mediante reglas de deducción

Una base mediante reglas de deducción u orientada a objeto. Surgen como una combinación de las BD y la
programación orientada a objeto. BDR: persistencia, concurrencia, recuperación, facilidad de consultas. BDOO:
objetos, encapsulamiento, tipos de clases, herencia, identidad de objeto.
Suministro múltiple de interfaces con los usuarios

Como podemos tener una gran variedad de usuarios y con diversos niveles de conocimientos el SGBD debe con-
tar con diferentes interfaces para los diferentes usuarios.
Vínculos complejos entre los datos

Una BD puede contener numerosos conjuntos de datos que estén relacionados entre si de muchas maneras. Es
preciso que el SGBD pueda representar diversos vínculos complejos de bases de datos y también obtener y ac-
tualizar con rapidez y eficiencia datos que estén mutuamente relacionados.
Cumplimiento de las restricciones de integridad

Cuando hablamos de restricciones de integridad nos referimos a restricciones de los datos que las aplicaremos
mediante el SGBD. La forma más fácil de restringir la integridad consiste en especificar un tipo de datos para cada
elemento de información. Ej el campo grado de primaria no va ser texto sino que numérico y a su ves no va tener
mas de una posición numérica ya que no tenemos grados de dos dígitos.
Respaldo y recuperación
Respaldo y recuperación se refiere a la recuperación ante falla de hardware o software del SGBD. Si por algún
motivo el SGBD falla debe volver a la instancia anterior a la falla.
Funciones y lenguajes de SGBD

Los SGBD tienen que realizar tres tipos de funciones para ser considerados válidos.
33
Función de descripción o de definición

Permite al diseñador de la base de datos crear las estructuras apropiadas para integrar adecuadamente los datos.
Este función es la que permite definir las tres estructuras de la base de datos (relacionadas con sus tres esquemas).
• Estructura interna
• Estructura conceptual
• Estructura externa
Esta función se realiza mediante el lenguaje de descripción de datos o DDL. Mediante ese lenguaje:
• Se definen las estructuras de datos

• Se definen las relaciones entre los datos
• Se definen las reglas que han de cumplir los datos
Función de manipulación
Permite modificar y utilizar los datos de la base de datos. Se realiza mediante el lenguaje de modificación de da-
tos o DML. Mediante ese lenguaje se puede:
• Añadir datos
• Eliminar datos
• Modificar datos
• Buscar datos
Actualmente se suele distinguir aparte la función de buscar datos en la base de datos (función de consulta). Para
lo cual se proporciona un lenguaje de consulta de datos o DQL.
Función de control
Mediante esta función los administradores poseen mecanismos para proteger las visiones de los datos permiti-
das a cada usuario, además de proporcionar elementos de creación y modificación de esos usuarios.
Se suelen incluir aquí las tareas de copia de seguridad, carga de ficheros, auditoria, protección ante ataques exter-
nos, configuración del sistema... El lenguaje que implementa esta función es el lenguaje de control de datos o DCL.
Estructura multicapas del SGBD

El proceso que realiza un SGBD está en realidad formado por varias
capas que actúan como interfaces entre el usuario y los datos. Fue
el propio organismo ANSI (en su modelo X3/SPARC que luego se co-
menta) la que introdujo una mejora de su modelo de bases de datos
en 1988 a través de un grupo de trabajo llamado UFTG (User Facili-
ties Task Group, grupo de trabajo para las facilidades de usuario). Este
modelo toma como objeto principal al usuario habitual de la base de
datos y modela el funcionamiento de la base de datos en una suce-
sión de capas cuya finalidad es ocultar y proteger la parte interna de
las bases de datos.
Desde esta óptica para llegar a los datos hay que pasar una serie de
capas que desde la parte más externa poco a poco van entrando más
en la realidad física de la base de datos.
Gráfico 13 - Modelo de referencia de las facilidades del usuario.

34
Base de Datos
Facilidades del usuario: Son las herramientas que proporciona el SGBD a los usuarios para permitir un acceso
más sencillo a los datos. Actúan de interfaz entre el usuario y la base de datos, y son el único elemento que ma-
neja el usuario.
Capa de acceso a datos: La capa de acceso a datos es la que permite comunicar a las aplicaciones de usuario con
el diccionario de datos a través de las herramientas de gestión de datos que incorpore el SGBD.
Diccionario de datos (del SGBD): Se trata del elemento que posee todos los metadatos. Gracias a esta capa las
solicitudes de los clientes se traducen en instrucciones que hacen referencia al esquema interno de la base de
datos.
Núcleo: El núcleo de la base de datos es la encargada de traducir todas las instrucciones requeridas y prepararlas
para su correcta interpretación por parte del sistema. Realiza la traducción física de las peticiones.
Sistema operativo: Es una capa externa al software SGBD pero es la única capa que realmente accede a los datos en sí.
Funcionamiento del SGBD

El esquema anterior reproduce la comunicación entre un proceso de usuario que desea acceder a los datos y el SGBD:
Gráfico 14 - Esquema del

funcionamiento del SGBD.
(1) El proceso lanzado por el usuario llama al SGBD indicando la porción de la base de datos que se desea tratar
(2) El SGBD traduce la llamada a términos del esquema lógico de la base de datos. Accede al esquema lógico
comprobando derechos de acceso y la traducción física (normalmente los metadatos se guardan una zona de
memoria global y no en el disco)
(3) El SGBD obtiene el esquema físico
(4) El SGBD traduce la llamada a los métodos de acceso del Sistema Operativo que permiten acceder realmente
a los datos requeridos
(5) El Sistema Operativo accede a los datos tras traducir las órdenes dadas por el SGBD
(6) Los datos pasan del disco a una memoria intermedia o buffer. En ese buffer se almacenarán los datos según
se vayan recibiendo.
(7) Los datos pasan del buffer al área de trabajo del usuario (ATU) del proceso del usuario. Los pasos 6 y 7 se repi-
ten hasta que se envíe toda la información al proceso de usuario.
(8) En el caso de que haya errores en cualquier momento del proceso, el SGBD devuelve indicadores en los que
manifiesta si ha habido errores o advertencias a tener en cuenta. Esto se indica al área de comunicaciones del
proceso de usuario. Si las indicaciones son satisfactorias, los datos de la ATU serán utilizables por el proceso
de usuario.
35
SGBD Comerciales
MySQL:
Es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de insta-
laciones. MySQL AB desarrolla MySQL como software libre en un esquema de licenciamiento dual. Por un lado lo
ofrece bajo la GNU GPL, pero, empresas que quieran incorporarlo en productos privativos pueden comprar a la
empresa una licencia que les permita ese uso.
Está desarrollado en su mayor parte en ANSI C.

Al contrario de proyectos como el Apache, donde el software es desarrollado por una comunidad pública, y el
copyright del código está en poder del autor individual, MySQL es propiedad y está patrocinado por una empresa
privada, que posee el copyright de la mayor parte del código. Esto es lo que posibilita el esquema de licencia-
miento anteriormente mencionado. Además de la venta de licencias privativas, la compañía ofrece soporte y
servicios. Para sus operaciones contratan trabajadores alrededor del mundo que colaboran vía Internet. MySQL
AB fue fundado por David Axmark, Allan Larsson, y Michael Widenius.
Oracle:
Es un sistema de gestión de base de datos relacional (o RDBMS por el acrónimo en inglés de Relational Data Base
Management System), fabricado por Oracle Corporation.
Se considera a Oracle como uno de los sistemas de bases de datos más completos, destacando su:
• Soporte de transacciones.
• Estabilidad.
• Escalabilidad.
• Es multiplataforma.
Su mayor defecto es su enorme precio, que es de varios miles de dólares (según versiones y licencias). Otro aspec-
to que ha sido criticado por algunos especialistas es la seguridad de la plataforma, y las políticas de suministro de
parches de seguridad, modificadas a comienzos de 2005 y que incrementan el nivel de exposición de los usuarios.
En los parches de actualización provistos durante el primer semestre de 2005 fueron corregidas 22 vulnerabilida-
des públicamente conocidas, algunas de ellas con una antigüedad de más de 2 años.
Aunque su dominio en el mercado de servidores empresariales ha sido casi total hasta hace poco, recientemente
sufre la competencia del Microsoft SQL Server de Microsoft y de la oferta de otros SGBD con licencia libre como
PostgreSQL, MySql o Firebird. Las últimas versiones de Oracle han sido certificadas para poder trabajar bajo Linux.
Paradox (base de datos):
Base de datos relacional para entorno MS Windows, anteriormente disponible para MS-DOS y Linux, desarrollada
actualmente por Corel e incluida en la suite ofimática WordPerfect Office.
En los tiempos del MS-DOS, era una base de datos de bastante éxito, compitiendo con dBase, Clipper y FoxBase.
Pasó al control de Borland después de la compra de Ansa Software en 1987.
Aunque Borland la portó a Windows, su cuota de mercado es mucho menor que la de Microsoft Access, pero su
lenguaje de programación (Objectpal) es Pascal lo que le hace más potente que Access que usa Visual Basic que
limita bastante sus prestaciones si se compara con otras bases de datos que usan lenguajes más avanzados. Con
su Runtime se puede desarrollar una aplicación usando una sola licencia sin limitación de puestos.
Microsoft SQL Server:

Es un sistema de gestión de bases de datos relacionales basado en el lenguaje Transact-SQL, capaz de poner a
disposición de muchos usuarios grandes cantidades de datos de manera simultánea. Así de tener unas ventajas
que a continuación se pueden describir.
36
Base de Datos
Entre sus características figuran:
• Soporte de transacciones.
• Escalabilidad, estabilidad y seguridad.
• Soporta procedimientos almacenados.
• Incluye también un potente entorno gráfico de administración, que permite el uso de comandos DDL y
DML gráficamente.
• Permite trabajar en modo cliente-servidor donde la información y datos se alojan en el servidor y las termi-
nales o clientes de la red sólo acceden a la información.
• Además permite administrar información de otros servidores de datos
Este sistema incluye una versión reducida, llamada MSDE con el mismo motor de base de datos pero orientado a
proyectos más pequeños, que en su versión 2005 pasa a ser el SQL Express Edition.
Microsoft SQL Server constituye la alternativa de Microsoft a otros sistemas gestores de bases de datos como son
Oracle, Sybase ASE o MySQL.
Es común desarrollar completos proyectos complementando Microsoft SQL Server y Microsoft Access a través
de los llamados ADP (Access Data Project). De esta forma se completa una potente base de datos (Microsoft SQL
Server) con un entorno de desarrollo cómodo y de alto rendimiento (VBA Access) a través de la implementación
de aplicaciones de dos capas mediante el uso de formularios Windows.
Para el desarrollo de aplicaciones más complejas (tres o más capas), Microsoft SQL Server incluye interfaces de
acceso para varias plataformas de desarrollo, entre ellas .NET.
Microsoft SQL Server, al contrario de su más cercana competencia, no es multiplataforma, ya que sólo está dispo-
nible en Sistemas Operativos de Microsoft.
Microsoft Access:
Es un sistema de gestión de bases de datos Relacional creado y modificado por Microsoft (DBMS) para uso per-
sonal de pequeñas organizaciones. Es un componente de la suite Microsoft Office aunque no se incluye en el
paquete “básico”. Una posibilidad adicional es la de crear ficheros con bases de datos que pueden ser consultados
por otros programas.
Características:
Entre las principales funcionalidades de Access se encuentran:
• Crear tablas de datos indexadas.

• Modificar tablas de datos.
• Relaciones entre tablas (creación de bases de datos relacionales).
• Creación de consultas y vistas.
• Consultas referencias cruzadas.
• Consultas de acción (INSERT, DELETE, UPDATE).
• Formularios.
• Informes.
• Llamadas a la API de windows.
• Interacción con otras aplicaciones que usen VBA (resto de aplicaciones de Microsoft Office, Autocad, etc.).
• Macros.
• Interconexión con entornos de bases de datos de gran nivel (como por ejemplo SQL Server) a través de
vinculación.
• Soporte de lectura de sistemas de archivos individuales (como FoxBase y similares) a través de vinculación
e importación de datos.
37
Además, permite crear frontends – o programa que muestra la interfaz de usuario – de bases de datos más po-
tentes ya que es un sistema capaz de acceder a tablas externas a través de ODBC como si fueran tablas Access.
Generalidades:
Es un software de gran difusión entre pequeñas empresas (PYMES) cuyas bases de datos no requieren de excesiva
potencia, ya que se integra perfectamente con el resto de aplicaciones de Microsoft y permite crear pequeñas
aplicaciones con unos pocos conocimientos de programación.
Tiene un sistema de seguridad de cifrado bastante primitivo y puede ser la respuesta a proyectos de programa-
ción de pequeño y mediano tamaño.
Inconvenientes:
Para bases de datos de gran calibre (en cuanto a volumen de datos o de usuarios) es recomendable usar otros
sistemas como MySQL o Microsoft SQL Server, y código VBA (Visual Basic para Aplicaciones).
Entre sus mayores inconvenientes figuran que no es multiplataforma, pues sólo está disponible para sistemas
operativos de Microsoft, y que no permite transacciones. Su uso es inadecuado para grandes proyectos de soft-
ware que requieren tiempos de respuesta críticos o muchos accesos simultáneos a la base de datos.
DB2:
Es una marca comercial, propiedad de IBM, bajo la cual se comercializa el sistema de gestión de base de datos.
La versión más actual es DB2 9, la cual utiliza XML como motor, además el modelo que utiliza es el jerárquico en
lugar del modelo relacional que utilizan otros gestores.
Visual FoxPro:
Es un lenguaje de programación orientado a objetos y procedural, un Sistema Gestor de Bases de datos o Databa-
se Management System (DBMS), y desde la versión 7.0, un Sistema administrador de bases de datos relacionales,
producido por Microsoft.
Características:
Visual FoxPro ofrece a los desarrolladores un conjunto de herramientas para crear aplicaciones de bases de datos
para el escritorio, entornos cliente/servidor, tablet PC o para la Web.
Entre sus características se pueden enumerar:
• Capacidades poderosas y muy veloces para el manejo de datos nativos y remotos.

• Flexibilidad para crear todo tipo de soluciones de bases de datos.
• Lenguaje de programación Orientado a objetos.
• Utilización de sentencias SQL en forma nativa.
• Poderoso manejo de vistas y cursores y control completo de estructuras relacionales.
• Su propio gestor de base de datos incorporado. Sin embargo, también puede conectarse con servidores de
base de datos, tales como Oracle, Microsoft SQL Server o MySQL.
• Cuenta con un motor de generación de informes renovado y muy flexible para soluciones más robustas.
• Desde la versión 9.0, amplio soporte de XML, tanto como fuente de datos (por ej., servicios Web basados en
XML) como por generar reports en formato XLM.
• Desde la versión 7.0, soporte de la tecnología IntelliSense de Microsoft
La última versión liberada es la 9.0. La próxima versión, ‘Sedna’, será un poderoso y completo lenguaje que permitirá
al producto interactuar aun más con VisualStudio.net, SQLServer2005, SQLExpress2005 y Office12, Windows Vista.
No habrá una próxima versión llamada sedna, microsoft ha cancelado el desarrollo de dicha versión y lanzarán lo
que han hecho hasta ahora como un service pack, hay fecha de fin de soporte que es en el año 2015.
38
Base de Datos
Hay un movimiento que está haciendo presión para que microsoft continue, o deje el visual fox como código
abierto para que otra gente pueda seguir evolucionando.
La versión 9.0 de Visual FoxPro cuenta con el SP1 en la que hay algunas nuevas características y especialmente
brinda estabilidad al producto.
PostgreSQL.
Es un sistema de gestión de base de datos relacional orientada a objetos y libre, publicado bajo la licencia BSD.
Como muchos otros proyectos de código abierto, el desarrollo de PostgreSQL no es manejado por una empresa
y/o persona, sino que es dirigido por una comunidad de desarrolladores que trabajan de forma desinteresada,
altruista, libre y/o apoyada por organizaciones comerciales. Dicha comunidad es denominada el PGDG (PostgreS-
QL Global Development Group).
Características
Algunas de sus principales características son, entre otras:
1. Alta concurrencia: mediante un sistema denominado MVCC (Acceso concurrente multiversión, por sus si-
glas en inglés) PostgreSQL permite que mientras un proceso escribe en una tabla, otros accedan a la mis-
ma tabla sin necesidad de bloqueos. Cada usuario obtiene una visión consistente de lo último a lo que se
le hizo commit. Esta estrategia es superior al uso de bloqueos por tabla o por filas común en otras bases,
eliminando la necesidad del uso de bloqueos explícitos.....
2. Amplia variedad de tipos nativos: provee nativamente soporte para:

• Números de precisión arbitraria.
• Texto de largo ilimitado.
• Figuras geométricas (con una variedad de funciones asociadas).
• Direcciones IP (IPv4 e IPv6).
• Bloques de direcciones estilo CIDR.
• Direcciones MAC.
• Arrays.
Adicionalmente los usuarios pueden crear sus propios tipos de datos, los que pueden ser por completo indexa-
bles gracias a la infraestructura GiST de PostgreSQL. Algunos ejemplos son los tipos de datos GIS creados por el
proyecto PostGIS.
Otras características
1. Claves ajenas también denominadas Llaves ajenas o Claves Foráneas (foreign keys).
2. Disparadores (triggers): Un disparador o trigger se define como una acción específica que se realiza de
acuerdo a un evento, cuando éste ocurra dentro de la base de datos. En PostgreSQL esto significa la eje-
cución de un procedimiento almacenado basado en una determinada acción sobre una tabla específica.
Ahora todos los disparadores se definen por seis características:
• El nombre del disparador o trigger

• El momento en que el disparador debe arrancar
• El evento del disparador deberá activarse sobre...
• La tabla donde el disparador se activará
• La frecuencia de la ejecución
• La función que podría ser llamada
39
Entonces combinando estas seis características, PostgreSQL le permitirá crear una amplia funcionalidad a través
de su sistema de activación de disparadores (triggers).
3. Vistas.
4. Integridad transaccional.
5. Herencia de tablas.
6. Tipos de datos y operaciones geométricas.
7. Soporte para transacciones distribuidas. Permite a PostgreSQL integrase en un sistema distribuido for-
mado por varios recursos (p.ej, una base de datos PostgreSQL, otra Oracle, una cola de mensajes IBM MQ
JMS y un ERP SAP) gestionado por un servidor de aplicaciones donde el éxito (“commit”) de la transacción
globlal es el resultado del éxito de las transacciones locales.
Resumen tema 4
Un SGBD es un conjunto de programas que permite a los usuarios crear y mantener una DB. El propósito general
de dicho SGBD es definir, construir y manipular BD de una manera mas transparente, es decir a la vista humana
los archivos de alto nivel.
Las características deseables en un SGBD.
1. Control de redundancia.
2. Restricción de accesos no autorizados.
3. Almacenamiento de objetos y estructuras de datos de programas.
4. Inferencias en la BD mediante reglas de deducción.
5. Suministro múltiple de interfaces con los usuarios.
6. Recuperación de vínculos complejos entre los datos.
7. Cumplimiento de las restricciones de integridad.
8. Respaldo y recuperación.
Funciones y lenguajes de SGBD

• Función de descripción o de definición: Permite al diseñador de la base de datos crear las estructuras apro-
piadas para integrar adecuadamente los datos. Esta función se realiza mediante el lenguaje de descripción
de datos o DDL.
• Función de manipulación: Permite modificar y utilizar los datos de la base de datos. Se realiza mediante el
lenguaje de modificación de datos o DML
• Función de control: Mediante esta función los administradores poseen mecanismos para proteger las vi-
siones de los datos permitidas a cada usuario. El lenguaje que implementa esta función es el lenguaje de
control de datos o DCL.
Estructura multicapas del SGBD

El proceso que realiza un SGBD está en realidad formado por varias capas que actúan como interfaces entre el
usuario y los datos. Este modelo toma como objeto principal al usuario habitual de la base de datos, su finalidad
es ocultar y proteger la parte interna de las bases de datos.
40
Base de Datos
Autoevaluación
1. ¿Qué es un sistema de gestión de base de datos?
2. Dentro de las características deseables ¿Qué entiende por Control de redundancia?
3. Para que solo los usuarios de la base de datos de recursos humanos vean los sueldos de la organización de que
característica del SGBD me voy valer.
4. ¿Que característica del SGBD interviene implícitamente en lo cotidiano cuando en la oficina a las 9 de la maña-
na todos los usuarios se conectan con una misma base?
5. ¿Que característica del SGBD en una restricción de una tabla que si es menor de 17 años no me deje cargar el
número de la licencia de conducir?
6. Dentro de las características deseables ¿Cómo explicaría en que consiste la recuperación y respaldo?
7. ¿Cuáles son los lenguajes que utiliza el SGBD?
8. ¿Cuál es la función de la estructura multicapas del SGBD?
Investigación
1. Indague cuales son los SGBD mas usados.
2. Averigüe si todos son licenciados o hay alguno GNU.
3. Lea de Concepción y diseño de base datos del Modelo E/R al Modelo Relacional - Adoración de Miguel, Mario
Piattini. Ra-ma. Capitulo 2 Concepto y objetivos de los sistemas de base de datos.
Tema Nº 5
Usuarios de los gestores de base de datos
Intervienen (como ya se ha comentado) muchas personas en el desarrollo y manipulación de una base de datos.
Habíamos seleccionado cuatro tipos de usuarios (administradores/as, desarrolladores, diseñadores/as y usuarios/
as). Ahora vamos a desglosar aún más esta clasificación.
Lógicamente son los profesionales que definen y preparan la base de datos. Pueden ser:
• Directivos/as. Organizadores y coordinadores del proyecto a desarrollar y máximos responsables del mis-
mo. Esto significa que son los encargados de decidir los recursos que se pueden utilizar, planificar el tiempo
y las tareas, la atención al usuario y de dirigir las entrevistas y reuniones pertinentes.
• Analistas. Son los encargados de controlar el desarrollo de la base de datos aprobada por la dirección.
Normalmente son además los diseñadores de la base de datos (especialmente de los esquemas interno y
conceptual) y los directores de la programación de la misma.
• Administradores/as de las bases de datos. Encargados de crear el esquema interno de la base de datos, que
incluye la planificación de copia de seguridad, gestión de usuarios y permisos y creación de los objetos de
la base de datos.
• Desarrolladores/as o programadores/as. Encargados de la realización de las aplicaciones de usuario de la

base de datos.
• Equipo de mantenimiento. Encargados de dar soporte a los usuarios en el trabajo diario (suelen incorporar
además tareas administrativas como la creación de copias de seguridad por ejemplo o el arreglo de proble-
mas de red por ejemplo).
41
Usuarios:
• Expertos/as. Utilizan el lenguaje de manipulación de datos (DML) para acceder a la base de datos. Son usua-
rios que utilizan la base de datos para gestión avanzada de decisiones.
• Habituales. Utilizan las aplicaciones creadas por los desarrolladores para consultar y actualizar los datos.
Son los que trabajan en la empresa a diario con estas herramientas y el objetivo fundamental de todo el
desarrollo de la base de datos.
• Ocasionales. Son usuarios que utilizan un acceso mínimo a la base de datos a través de una aplicación que
permite consultar ciertos datos. Serían por ejemplo los usuarios que consultan el horario de trenes a través
de Internet.
Estándar ANSI/SPARC, SGBD.

El objetivo principal de la arquitectura ANSI/SPARC es definir un SGBD con el máximo grado de independencia,
separando las aplicaciones de usuario y la base de datos física. Para ello se utilizan tres niveles de abstracción
conocidos como interno, conceptual y externo.
1. El nivel interno es el más cercano a la máquina. Es una representación a bajo nivel de la BD en la que se de-
fine la forma en la que los datos se almacenan físicamente en la máquina. Se definen características como
los dispositivos en donde se almacenan los datos, el espacio que se reserva, las estrategias de acceso, la
creación de ficheros de índices, etc. Es dependiente de la máquina en que se vaya a instalar la BD, del sis-
tema operativo que exista, etc.
2. El nivel conceptual tiene un esquema conceptual, que describe la estructura de los datos que van a ser
almacenados en la base de datos. El esquema conceptual esconde los detalles del almacenamiento físico
y se concentra en describir entidades, tipos de datos, relaciones, operaciones de usuario y restricciones.
3. El nivel externo o nivel de vista incluye varios esquemas externos o vistas de usuario. Cada esquema ex-
terno describe la parte de la base de datos en la que está interesado un grupo de usuarios en particular y
esconde el resto de la base de datos para esos usuarios. La información se manipula sin saber cómo está
almacenada internamente (nivel interno) ni su organización (nivel conceptual).
Existirán muchas vistas externas distintas, cada una formada por una representación más o menos abstracta
(registros y campos lógicos) de alguna parte de la base de datos total, y existirá sólo una vista conceptual forma-
da por una representación igualmente abstracta de la base de datos en su totalidad (hay que recordar que a la
mayoría de los usuarios no les interesará toda la base de datos, sino sólo una porción limitada de ella). De manera
similar, habrá sólo una vista interna, la cual representará a toda la base de datos tal como está almacenada física-
mente.
El Nivel Externo
El nivel externo es el más cercano a los usuarios, es decir, es el que se ocupa de la forma en la que los usuarios
perciben los datos. El nivel externo es del usuario individual. Estos usuarios pueden ser o bien programadores de
aplicaciones o usuarios finales con conocimientos muy variables de informática. El administrador de la base de
datos es un caso especial (también debe interesarse por los demás niveles de la arquitectura).
42
Base de Datos
Cada usuario dispone de un lenguaje:

En el caso del programador de aplicaciones, dicho lenguaje será o bien un lenguaje de programación conven-
cional, o bien un lenguaje de cuarta generación (4GL) específico para el sistema en cuestión. Para el usuario final
será o bien un lenguaje de consulta, o algún lenguaje de aplicación especial, quizá manejado mediante formas o
menús, adaptado a los requerimientos de ese usuario y apoyado por algún programa de aplicación en línea (cuya
función es servir a un usuario final que tiene acceso a la base de datos desde una terminal en línea).
El aspecto importante de todos estos lenguajes es que deben incluir un sublenguaje de datos, es decir, un sub-
conjunto del lenguaje total que se ocupe de manera específica de los objetos y operaciones de la base de datos.
Se dice que el sublenguaje de datos (DSL ‘data sublanguage’) está embebido (o inmerso) dentro del lenguaje
anfitrión correspondiente. Este último se encarga de varios aspectos no relacionados con la base de datos, como
por ejemplo variables locales (temporales), operaciones de cálculo, lógica condicional, etc. Un sistema dado pue-
de permitir el empleo de varios lenguajes anfitriones y varios sublenguajes de datos. Un sublenguaje de datos en
particular cuyo uso es posible en casi todos los sistemas relacionales actuales es el lenguaje SQL.
En principio, cualquier sublenguaje de datos es en realidad una combinación de por lo menos dos lenguajes
subordinados: un lenguaje de definición de datos (DDL ‘data definition language’), con el cual es posible definir
o declarar los objetos de la base de datos, y un lenguaje de manipulación de datos (DML, ‘data manipulation
language’) con el que es posible manipular o procesar dichos objetos. Como ya se ha dicho, al usuario individual
(en general), sólo le interesará una porción de la base de datos total; por añadidura, la forma como ese usuario
percibe dicha porción casi siempre será un tanto abstracta comparada con el almacenamiento físico de los datos.
El término ANSI/SPARC para la vista individual de un usuario es vista externa. Así, una vista externa es el conteni-
do de la base de datos tal como lo percibe algún usuario determinado (es decir, para ese usuario la vista externa
es la base de datos). Por ejemplo, un usuario del departamento de personal podría contemplar la base de datos
como un conjunto de ocurrencias de registros de departamento unido a un conjunto de ocurrencias de registros
de proveedor y de parte vistas por los usuarios del departamento de compras).
Toda vista externa se define mediante un esquema externo, que consiste básicamente en definiciones de cada
uno de los diversos tipos de registros externos en esa vista externa. El esquema externo se escribe con la porción
DDL del sublenguaje de datos del usuario (por ello se le denomina a ese DDL en ocasiones como DDL externo).
Por ejemplo, el tipo de registro externo de empleado puede definirse como un campo de número de empleado
de seis caracteres unido a un campo de salario de cinco dígitos, etc. Además, debe haber una definición de la
correspondencia entre el esquema externo y el esquema conceptual subyacente.
El Nivel Conceptual
El nivel conceptual es un nivel de mediación entre el nivel interno y externo. La vista conceptual es una represen-
tación de toda la información contenida en la base de datos, también (como en el caso de una vista externa) en
una forma un tanto abstracta si se compara con el almacenamiento físico de los datos.
Además, puede ser muy diferente de la forma como percibe los datos cualquier usuario individual. A grandes
rasgos, la vista conceptual debe ser un panorama de los datos “tal como son”, y no como por fuerza los perciben
los usuarios debido a las limitaciones del lenguaje o el equipo específicos utilizados, por ejemplo.
La vista conceptual se compone de varias ocurrencias de varios tipos de registro conceptual. Por ejemplo, puede
estar formada por un conjunto de ocurrencias de registros de departamento unido un conjunto de ocurrencias
de registro de empleado y a un conjunto de ocurrencias de registros de proveedor y a un conjunto de ocurrencia
de registros de parte... Un registro conceptual no es por necesidad idéntico a un registro externo, por un lado, ni
a un registro almacenado, por el otro.
La vista conceptual se define mediante un esquema conceptual, el cual incluye definiciones de cada uno de los
tipos de registro conceptual. El esquema conceptual se escribe utilizando otro lenguaje de definición de datos, el
DDL conceptual. Si ha de lograrse la independencia de los datos, esas definiciones en DDL conceptual no debe-
rán implicar consideraciones de estructura de almacenamiento o de técnica de acceso. Si el esquema conceptual
se hace en verdad independiente de los datos de esta manera, entonces los esquemas externos, definidos en
términos del esquema conceptual, serán por fuerza también independientes de los datos.
43
Así pues, la vista conceptual es una vista del contenido total de la base de datos, y el esquema conceptual es
una definición de esa vista. No obstante, sería engañoso sugerir mucho más que una simple unión de todos los
esquemas externos individuales, con la posible adición de algunas verificaciones sencillas de integridad y seguri-
dad. Con todo, parece evidente que los sistemas del futuro llegarán a mantener niveles conceptuales mucho más
complejos.que el esquema conceptual es sólo un conjunto de definiciones similar a las sencillas definiciones de
registros encontradas por ejemplo en un programa en Cobol. Es de esperar que las definiciones en el esquema
conceptual incluyan muchas características más, como son las verificaciones de seguridad y de integridad. Al-
gunos expertos podrían llegar a sugerir que el objetivo primordial del esque conceptual es describir la empresa
en su totalidad (no sólo los datos en sí, sino también la forma como se utilizan: cómo fluyen de un punto a otro
dentro de la empresa, qué se hace con ellos en cada punto, qué controles de auditoría o de otro tipo deben apli-
carse en cada punto, etc. Debe hacerse hincapié en que en ningún sistema actual es posible mantener realmente
un nivel conceptual que se aproxime siquiera a ese grado de complejidad; en casi todos los sistemas existentes el
esquema conceptual no es mucho más que una simple unión de todos los esquemas externos individuales, con
la posible adición de algunas verificaciones sencillas de integridad y seguridad. Con todo, parece evidente que
los sistemas del futuro llegarán a mantener niveles conceptuales mucho más complejos.
El Nivel interno
El tercer nivel de la arquitectura es el nivel interno. La vista interna es una representación de bajo nivel de toda la
base de datos; se compone de varias ocurrencias de varios tipos de registro interno. Este último término es el que
utiliza ANSI/SPARC para referirse a la construcción que hemos estado llamando registro almacenado. La vista inter-
na, por tanto, todavía está a un paso del nivel físico, ya que no manejo registros físicos (llamados también páginas
o bloques), ni otras consideraciones específicas de los dispositivos como son los tamaños de cilindros o de pistas.
La vista interna se define mediante el esquema interno, el cual no sólo define los diversos tipos de registros alma-
cenados sino también especifica que índices hay, cómo se representan los campos almacenados, en qué secuen-
cia física se encuentran los registros almacenados, etc. El esquema interno se escribe con otro lenguaje más de
definición de datos, el DDL interno.
En algunas situaciones excepcionales podría permitirse a los programas de aplicación operar directamente en el
nivel interno en vez de hacerlo en el nivel externo. Esta práctica no es recomendable ya que representa un riesgo
para la seguridad (ya que pasan por alto las verificaciones de seguridad) y para la integridad (hace lo mismo), y el
programa será en extremo dependiente de los datos; sin embargo, en ciertos casos puede ser la única forma de
obtener la función o desempeño deseados, del mismo modo como el usuario de un lenguaje de programación de
alto nivel puede verse obligado en ocasiones a descender al lenguaje ensamblador para satisfacer ciertos objetivos.
Correspondencias, asociaciones o ligaduras (mappings)

Para describir un mismo grupo de datos, un sistema puede gestionar varios niveles de esquemas,para lo cual el
DBMS debe poder garantizar la transferencia de los datos desde el formato correspondiente de un nivel al forma-
to correspondiente a otro nivel; este proceso se denomina transformación de datos o mapping.
Hay dos niveles de correspondencia en la arquitectura ANSI/SPARC: uno entre los niveles externo y conceptual
del sistema, y otro entre los niveles conceptual e interno. La correspondencia conceptual/interna es la que exis-
te entre las vistas conceptuales y la base de datos almacenada; especifica cómo se representan los registros y
campos conceptuales en el nivel interno. Si se modifica la estructura de la base de datos almacenada (es decir, si
se altera la definición de la estructura de almacenamiento), la correspondencia conceptual/interna deberá mo-
dificarse también de acuerdo con ello, para que no varíe el esquema conceptual (el administrador de la base de
datos se debe encargar de controlar tales modificaciones). Dicho de otra manera, los efectos de las alteraciones
deberán aislarse por debajo del nivel conceptual, a fin de conservar la independencia de los datos.
La correspondencia externa/conceptual es la que existe entre una determinada vista externa y la vista concep-
tual. Las diferencias que pueden existir entre estos dos niveles son similares a las que pueden existir entre la vista
conceptual y la base de datos almacenada. Por ejemplo, los campos pueden tener distintos tipos de datos, los
nombres de los campos y los registros pueden diferir, pueden combinarse varios campos conceptuales para for-
mar un solo campo externo (virtual), etc. Puede existir cualquier cantidad de vistas externas; cualquier número
de usuarios puede compartir una determinada vista externa.
44
Base de Datos
Algunos sistemas permiten expresar la definición de una vista externa en términos de otras (de hecho, a través de
una correspondencia externa/externa), en vez de requerir siempre una definición explícita de la correspondencia
respecto al nivel conceptual, cosa que resulta útil si existe una relación muy grande entre varias vistas externas.
Los sistemas relacionales en particular casi siempre permiten hacer esto.
Gráfico 15 - Modelo ANSI para un sistema gestor de bases de datos.
Gráfico 16 - Arquitectura ANSI para un sistema gestor de bases de datos.
45
La arquitectura completa (Gráfico 16) está dividida en dos secciones, la zona de definición de datos y la de mani-
pulación. Esa arquitectura muestra las funciones realizadas por humanos y las realizadas por programas.
En la fase de definición, una serie de interfaces permiten la creación de los metadatos que se convierten en el eje
de esta arquitectura. La creación de la base de datos comienza con la elaboración del esquema conceptual reali-
zándola el administrador de la empresa (actualmente es el diseñador de base de datos, pero ANSI no lo llamó así).
Ese esquema se procesa utilizando un procesador del esquema conceptual (puede utilizarse una herramienta
CASE) que lo convierte en los metadatos (interfaz 2).
La interfaz 3 permite mostrar los datos del esquema conceptual a los otros dos administradores: el administrador
de la base de datos y el de aplicaciones (el desarrollador). Mediante esta información construyen los esquemas
internos y externos mediante las interfaces 4 y 5 respectivamente, los procesadores de estos esquemas almace-
nan la información correspondiente a estos esquemas en los metadatos (interfaces 6 y 7).
En la fase de manipulación el usuario puede realizar operaciones sobre la base de datos usando la interfaz 8 (nor-
malmente una aplicación) esta petición es transformada por el transformador externo/conceptual que obtiene
el esquema correspondiente ayudándose también de los metadatos (interfaz 9). El resultado lo convierte otro
transformador en el esquema interno (interfaz 10) usando también la información de los metadatos (interfaz 11).
Finalmente del esquema interno se pasa a los datos usando el último transformador (interfaz 12) que también
accede a los metadatos (interfaz 13) y de ahí se accede a los datos (interfaz 14). Para que los datos se devuelvan al
usuario en formato adecuado para él se tiene que hacer el proceso contrario (observar el Gráfico).
Proceso de creación y manipulación de una base de dato propuesta por ANSI

El modelo ANSI de bases de datos sigue estando vigente y por ello el ciclo de vida de una base de datos continúa
atendiendo a las directrices marcadas por el modelo. No obstante sí han cambiado el nombre de los recursos
humanos.
Fase de creación
1. El analista o diseñador (equivalente a un administrador de esquemas conceptuales del modelo ANSI) utili-
za una herramienta CASE para crear el esquema conceptual.
2. El administrador de la base de datos (DBA) crea el esquema interno utilizando las herramientas de defini-
ción de datos del SGBD y herramientas CASE.
3. Los desarrolladores utilizan las aplicaciones necesarias para generar el esquema externo mediante herra-
mientas de creación de aplicaciones apropiadas y herramientas CASE.
Fase de manipulación
1. El usuario realiza una consulta utilizando el esquema externo.
2. Las aplicaciones las traducen a su forma conceptual.
3. El esquema conceptual es traducido por la SGBD a su forma interna.
4. EL Sistema Operativo accede al almacenamiento físico correspondiente y devuelve los datos al SGBD.
5. El SGBD transforma los datos internos en datos conceptuales y los entrega a la aplicación.
6. La aplicación muestra los datos habiéndolos traducido en su forma externa. Así los ve el usuario.
46
Base de Datos
Estructuras operacionales de los SDGB
Actualmente casi todos los sistemas gestores de base de datos poseen también la misma idea operacional (la
misma forma de funcionar con el cliente) en la que se entiende que la base de datos se almacena en un servidor
y hay una serie de clientes que pueden acceder a los datos del mismo. Las posibilidades son:
• Estructura Cliente-Servidor. Estructura clásica, la base de datos y su SGBD están en un servidor al cual acce-
den los clientes. El cliente posee software que permite al usuario enviar instrucciones al SGBD en el servidor
y recibir los resultados de estas instrucciones. Para ello el software cliente y el servidor deben utilizar soft-
ware de comunicaciones en red.
• Cliente multi-servidor. Ocurre cuando los clientes acceden a datos situados en más de un servidor. También
se conoce esta estructura como base de datos distribuida. El cliente no sabe si los datos están en uno o más
servidores, ya que el resultado es el mismo independientemente de dónde se almacenan los datos. En esta
estructura hay un servidor de aplicaciones que es el que recibe las peticiones y el encargado de traducirlas
a los distintos servidores de datos para obtener los resultados.
• Cliente-Servidor con facilidades de usuario-Servidor de base de datos. Se trata de una forma de conexión
por el que los clientes no conectan directamente con la base de datos sino con un intermediario (normal-
mente un Servidor Web) que tiene una mayor facilidad para comunicarse con los usuarios. Ese servidor se
encarga de traducir lo que el cliente realiza a una forma entendible por la base de datos.
Características de una estructura cliente servidor

Un sistema cliente/servidor es aquel en el que uno o más clientes y uno o más servidores, conjuntamente con un
sistema operativo subyacente y un sistema de comunicación entre procesos, forma un sistema compuesto que
permite cómputo distribuido, análisis, y presentación de los datos. Si existen múltiples servidores de procesa-
miento de base de datos, cada uno de ellos deberá procesar una base de datos distinta, para que el sistema sea
considerado un sistema cliente/servidor. Cuando dos servidores procesan la misma base de datos, el sistema ya
no se llama un sistema cliente/servidor, sino que se trata de un sistema de base de datos distribuido. Los clientes,
a través de la red, pueden realizar consultas al servidor. El servidor tiene el control sobre los datos; sin embargo
los clientes pueden tener datos privados que residen en sus computadoras. Las principales características de la
arquitectura cliente/servidor son:
• El servidor presenta a todos sus clientes una interfaz única y bien definida.
• El cliente no necesita conocer la lógica del servidor, sólo su interfaz externa.
• El cliente no depende de la ubicación física del servidor, ni del tipo de equipo físico en el que se encuentra,
ni de su sistema operativo.
• Los cambios en el servidor implican pocos o ningún cambio en el cliente.
Como ejemplos de clientes pueden citarse interfaces de usuario para enviar comandos a un servidor, APIs (Apli-
cation Program Interface) para el desarrollo de aplicaciones distribuidas, herramientas en el cliente para acceder
a servidores remotos (por ejemplo, servidores de SQL) o aplicaciones que solicitan acceso a servidores para algu-
nos servicios.
Como ejemplos de servidores pueden citarse servidores de ventanas como X-windows, servidores de archivos
como NFS, servidores para el manejo de bases de datos (como los servidores de SQL), servidores de diseño y ma-
nufactura asistidos por computador, etc.
47
Partes de una estructura cliente servidor

Los principales componentes de un sistema cliente/servidor son:
1. El núcleo (back-end o sección posterior). Es el SGBD propiamente (servidor).

2. El interfaz (front-end o sección frontal). Aplicaciones que funcionan sobre el SGBD (cliente).
Ambiente cliente / Servidor Genérico
La diferencia entre la computación cliente/servidor y la computación centralizada multiusuario es que el cliente

no es un terminal “tonto”. El computador cliente tiene su propio sistema operativo y puede manejar entradas (te-
clado, ratón, etc.) y salidas (pantalla, impresora local, sonido, etc.) sin el servidor. El papel del servidor es esperar
pasivamente la petición de servicio del cliente. Esta distribución del proceso permite al cliente ofrecer un am-
biente de trabajo más amigable que un terminal “tonto” (interfaz de usuario gráfica, aplicaciones locales, ratón,
etc.) y permite al servidor ser menos complejo y caro que los sistemas mainframe. El conjunto de la computación
cliente/servidor conduce a un ambiente flexible y dinámico.
La parte cliente de la aplicación maneja la entrada de datos, acepta consultas de los usuarios y muestra los resul-
tados. La parte cliente no procesa las consultas. En su lugar, envía la consulta del usuario al computador servidor,
donde la parte servidor de la aplicación procesa la consulta. El servidor devuelve los resultados al cliente, que es
quien se las muestra al usuario.
La sección frontal o Frot- end

Las secciones frontales son las diversas aplicaciones ejecutadas dentro del SGBD, tanto las escritas por los usua-
rios como las “integradas” que son las proporcionadas por el proveedor del SGBD o bien por otros proveedores de
programas (aunque para la sección posterior no existe diferencia entre las aplicaciones escritas por los usuarios y
las integradas, ya que todas utilizan la misma interfaz con la sección posterior).
Funciones del cliente

• Administrar la interfaz gráfica de usuario.
• Aceptar datos del usuario.
• Procesar la lógica de la aplicación.
• Generar las solicitudes para la base de datos.
• Transmitir las solicitudes de la base de datos al servidor.
• Recibir los resultados del servidor.
• Dar formato a los resultados.
48
Base de Datos
Cómo trabaja la sección frontal

La secuencia de eventos que tiene lugar cuando el usuario accede al servidor de la base de datos se puede gene-
ralizar en 6 pasos básicos ilustrados en la figura. Para mayor simplicidad, el término consulta representa cualquier
acción que el usuario pueda hacer en la base de datos, como actualizar, insertar, borrar o pedir datos de la base
de datos.
Primero, el usuario crea la consulta. Puede ser una consulta creada en el instante o puede ser una consulta pre-
programada o almacenada anteriormente. Después la aplicación cliente convierte la consulta al SQL usado por
el servidor de la base de datos y la envía a través de la red al servidor. El servidor verifica que el usuario tiene los
derechos de seguridad apropiados a la consulta de datos requerida. Si es así, verifica la consulta y envía los datos
apropiados de vuelta al cliente. La aplicación cliente recibe la respuesta y le da formato para presentarlo al usuario.
Finalmente, el usuario ve la respuesta en la pantalla y puede manipular los datos, o modificar la consulta y empe-
zar el proceso de nuevo.
49
La sección posterior o Back - end

La sección posterior es el SGBD en sí. Permite llevar a cabo todas las funciones básicas de un SGBD: definición de
datos, manipulación de datos, seguridad, integridad, etc. En particular, permite establecer todos los aspectos de
los niveles externo, conceptual e interno (arquitectura ANSI/SPARC)
Funciones del servidor

• Aceptar las solicitudes de la base de datos de los clientes.
• Procesar dichas solicitudes.
• Dar formato a los resultados y transmitirlos al cliente.
• Llevar a cabo la verificación de integridad.
• Mantener los datos generales de la base de datos.
• Proporcionar control de acceso concurrente.
• Llevar a cabo la recuperación.
• Optimizar el procesamiento de consultas y actualización.
Tipos de servidores
Podemos dividir los servidores en dos clases: iterativos y concurrentes.
Un servidor iterativo realiza los siguientes pasos:
1. Espera que llegue una consulta de un cliente.
2. Procesa la consulta.
3. Envía la respuesta al cliente que envió la consulta.
4. Vuelve al estado inicial.
El problema del servidor iterativo es el paso 2. Durante el tiempo en el que el servidor está procesando la consul-
ta, ningún otro cliente es servido.
Un servidor concurrente realiza los siguientes pasos:

1. Espera que llegue la consulta de un cliente.
2. Cuando le llega una nueva consulta, comienza un nuevo proceso para manejar esta consulta (cómo se
realiza este paso depende del sistema operativo). El nuevo servidor maneja la totalidad de la consulta.
Cuando se ha procesado completamente, este nuevo proceso termina.
3. Se vuelve al primer paso.
La ventaja del servidor concurrente es que el servidor ejecuta un nuevo proceso para manejar cada consulta.
Cada cliente tiene su “propio” servidor. Asumiendo que el sistema operativo permite la multiprogramación, clien-
tes múltiples y servicio concurrente.
También podemos dividir los servidores en servidores de transacciones y servidores de datos.
Los sistemas servidores de transacciones, también llamados sistemas servidores de consultas, proporcionan una
interfaz a través de la cual los clientes pueden enviar peticiones para realizar una acción que el servidor ejecutará
y cuyos resultados se devolverán al cliente. Los usuarios pueden especificar sus peticiones con SQL o mediante
la interfaz de una aplicación utilizando un mecanismo de llamadas a procedimientos remotos (RPC: ‘Remote
Procedure Call’).
Los sistemas servidores de datos permiten que los clientes puedan interaccionar con los servidores realizando
peticiones de lectura o modificación de datos en unidades tales como archivos o páginas. Por ejemplo, los servi-
dores de archivos proporcionan una interfaz de sistema de archivos a través de la cual los clientes pueden crear,
modificar, leer y borrar archivos. Los servidores de datos de los sistemas de bases de datos ofrecen muchas más
funcionalidades; soportan unidades de datos de menor tamaño que los archivos, como páginas, tuplas u objetos.
50
Base de Datos
Proporcionan facilidades de indexación de los datos, así como facilidades de transacción, de modo que los datos
nunca se quedan en un estado inconsistente si falla una máquina cliente o un proceso.
Situación del Mercado de los SGBD y Estandarización

La mayoría de sistemas de gestión de bases de datos de hoy en día son relacionales, como se ha visto anterior-
mente. Además, el mercado está muy concentrado por tres compañías: Oracle, IBM y Microsoft. Según un estudio
de Dataquest (www.dataquest.com), ahora llamado Gartner Group (www.gartner.com), IBM y Oracle han estado
codo con codo durante los últimos años con cerca del 30% de ingresos por ventas de nuevas licencias en el mer-
cado de SGBD cada uno [Graham 2002].
No obstante, hay que destacar que la distribución de estos porcentajes no es uniforme en la gama de aplicaciones.
Por ejemplo, IBM sigue siendo líder en el área de los mainframes, especialmente con su línea 17 OS/390 y AS/400.
Por el contrario, si quitamos los mainframes, Oracle lidera el mercado con una gran ventaja. Según un último
estudio del Gartner Group, la situación en mayo de 2002 sigue siendo hegemónica para Oracle, IBM y Microsoft
[Nicolett 2002]. La gama de SGBD de Informix se ha venido a menos en cuota de mercado. De hecho en 2001, fue
absorbida por IBM, para que ésta aumentara su cuota en las plataformas Unix y Windows [Burton 2001]. Además,
si sumamos los SGBD de IBM actuales, incluyendo los absorbidos de Informix, tenemos la mayor cuota, un 34,7%
en 2001. No obstante, a medio plazo ocurrirá que muchos de los usuarios de Informix migren a DB2. Más aún si
tenemos en cuenta que IBM ha intentado aumentar su presencia mediante la potenciación de las versiones UNIX
y NT de su DB2, que han crecido considerablemente en los últimos años. Si atendemos al porcentaje de mercado
de los sistemas de gestión de bases de datos relacionales, podemos observar todavía una mayor concentración:
Considerando sólo los sistemas relacionales, mientras sobre sistemas operativos Windows, Microsoft es el líder
en 2001 con el 39.9% del mercado (respecto a un 34.0% de Oracle), en sistemas operativos UNIX, Oracle es clara-
mente predominante, con un 63.3%.
51
La excesiva concentración del mercado plantea serias dudas sobre la implantación del nuevo SQL3, porque las
compañías no tienen excesivo interés por hacer su SQL fácilmente portable a otros sistemas, con el riesgo de
poder perder clientes. No obstante, parte del nuevo SQL3 ha ido recogiendo los estándares ‘de facto’ que estas
mismas compañías han ido introduciendo, como el soporte para los objetos grandes incorporados (BLOB y LOB)
o los triggers, ambas extensiones presentes en el sistema emblema de Oracle, por ejemplo.
La incorporación de estas y otras extensiones de SQL3 (especialmente las orientadas a objeto y las consultas
recursivas) a la mayoría de sistemas será un proceso lento. De hecho, hoy en día, ningún sistema es todavía com-
pletamente compatible con todas las características de SQL2. El tema parece estar mucho peor para incorporar
las instrucciones de control y de definición de rutinas del SQL3 (CASE, IF, THEN, ELSE, ELSEIF, LOOP, WHILE, REPEAT,
FOR, ITERATE, LEAVE), ya que la mayoría de sistemas incorporan su propia sintaxis para los procedimientos, arras-
trada de sus lenguajes 4GL.
Resumen tema 5
Los profesionales que definen y preparan la base de datos. Pueden ser:
1. Directivos/as. Organizadores y coordinadores del proyecto a desarrollar y máximos responsables del mismo.
2. Analistas. Son los encargados de controlar el desarrollo de la base de datos aprobada por la dirección.
3. Administradores/as de las bases de datos. Encargados de crear el esquema interno de la base de datos, que
incluye la planificación de copia de seguridad, gestión de usuarios y permisos y creación de los objetos de
la base de datos.
4. Desarrolladores/as o programadores/as. Encargados de la realización de las aplicaciones de usuario de la
base de datos.
5. Equipo de mantenimiento. Encargados de dar soporte a los usuarios en el trabajo diario.
Usuarios:
1. Expertos/as. Utilizan el lenguaje de manipulación de datos (DML) para acceder a la base de datos. Son
usuarios que utilizan la base de datos para gestión avanzada de decisiones.
2. Habituales. Utilizan las aplicaciones creadas por los desarrolladores para consultar y actualizar los datos
3. Ocasionales. Son usuarios que utilizan un acceso mínimo a la base de datos a través de una aplicación que
permite consultar ciertos datos.
Arquitectura de los Sistemas gestores de base de datos

Es uno de los aspectos que todavía sigue pendiente, no hay estándares aceptados del todo. Aunque sí hay unas
cuentas propuestas de estándares que sí funcionan como tales.
El organismo ANSI ha marcado la referencia para la construcción de SGBD. El modelo definido por el grupo de
trabajo SPARC se basa en estudios anteriores en los que se definían tres niveles de abstracción necesarios para
gestionar una base de datos. ANSI profundiza más en esta idea y define cómo debe ser el proceso de creación y
utilización de estos niveles. En el modelo ANSI se indica que hay tres modelos: externo, conceptual e interno. Se
entiende por modelo, el conjunto de normas que permiten crear esquemas (diseños de la base de datos).
Proceso de creación y manipulación de una base de dato propuesta por ANSI
Fase de creación
• El analista o diseñador crea el esquema conceptual.
• El administrador de la base de datos (DBA) crea el esquema interno.
• Los desarrolladores utilizan las aplicaciones necesarias para generar el esquema externo.
52
Base de Datos
• El usuario realiza una consulta utilizando el esquema externo.
• Las aplicaciones las traducen a su forma conceptual.
• El esquema conceptual es traducido por la SGBD a su forma interna.
• EL Sistema Operativo accede al almacenamiento físico correspondiente y devuelve los datos al SGBD.
• El SGBD transforma los datos internos en datos conceptuales y los entrega a la aplicación.
• La aplicación muestra los datos habiéndolos traducido en su forma externa. Así los ve el usuario.
Estructuras operacionales
Actualmente casi todos los sistemas gestores de base de datos poseen también la misma idea operacional las
posibilidades son:
• Estructura Cliente-Servidor. Estructura clásica, la base de datos y su SGBD están en un servidor al cual acce-
den los clientes.
• Cliente multi-servidor. Ocurre cuando los clientes acceden a datos situados en más de un servidor.
• Cliente-Servidor con facilidades de usuario-Servidor de base de datos. Se trata de una forma de conexión
por el que los clientes no conectan directamente con la base de datos sino con un intermediario (normal-
mente un Servidor Web) que tiene una mayor facilidad para comunicarse con los usuarios.
Autoevaluación
1. Me proponen un trabajo para dar de alta usuarios en la base, realizar backups, controlar la performance y crear
restricciones. ¿Qué puesto es?
2. Cuando no me puedo conectar a una base de datos ¿a quien debería llamar?
3. ¿En qué se diferencian básicamente los usuarios de base de datos?
4. ¿Existe un estándar para los gestores de base de datos? Fundamentar.
5. En qué consiste el proceso de creación de una base de dato propuesta por ANSI.
6. En qué consiste el proceso de manipulación de una base de dato propuesta por ANSI.
7. Cuando saco dinero de un cajero automático, la operación de salida y actualización de saldo se hace en una
base de datos centralizada que no está en el mismo cajero. ¿Qué tipo de estructura operacional está en juego?
8. Cuando modifico mis datos en la pagina del banco (home banking) ¿Qué tipo de estructura operacional está
en juego?
Investigación
1. Investigue sobre herramientas case que ayuden a la creación de el modelo conceptual.
2. Sondee en paginas de ofertas de trabajo e investigue los requerimientos en funciones para el puedo de DBA.
3. Lea de Sistemas de base de datos – conceptos fundamentales – Elmasri - Navathe. Pearson educación.
Capitulo 1 Base de datos y usuarios.
53
Tema Nº 6
Diseño de base de datos
Introducción general al proceso de diseño de la base, para un mejor entendimiento los pasos se mostraran en un
orden dado, que en el desarrollo de los próximos módulos los vamos a modificar. Hecha esta aclaración podemos
seguir con el proceso de diseño de base de datos.
No sólo la tecnología es suficiente para que los sistemas de información de hoy en día funcionen mejor que los
de hace unos años. Asociadas a las tecnologías suelen asociarse unas metodologías, que intentan sacar provecho
de las primeras. Utilizar un sistema de gestión de bases de datos relacional no es por sí solo una garantía de que
el sistema de información que se construya utilizándolo vaya a funcionar bien. De hecho, dada la simplicidad del
modelo relacional y de algunos SGBR para ordenadores personales, existen verdaderos desastres realizados por
no profesionales funcionando en pequeñas y grandes organizaciones, causando casi más problemas de los que
resuelven.
A continuación se detallan los pasos usuales que se suelen utilizar a la hora de diseñar una base de datos. Gene-
ralmente se habla de las siguientes etapas: planificación-definición del sistema, análisis de requerimientos, dise-
ño conceptual, elección de SGBD/modelo, diseño lógico, diseño físico, implementación y ajuste de rendimiento.
Para las primeras tres etapas los pasos suelen ser bastante coincidentes (aunque con herramientas diferentes)
para las bases de datos relacionales y las objetuales, notándose más la diferencia en las cuatro últimas etapas.
1. Planificación y definición del sistema: aunque a veces estas fases se engloban en la siguiente fase de análisis de
requerimientos, consisten en determinar cuáles van a ser las fases del diseño de la base de datos y dar una visión
global del sistema.
2. Análisis de requerimientos: En esta fase de un proyecto, el mayor objetivo es proporcionar una imagen más
clara del sistema de información cuyos datos se quiere informatizar. Para ello se deben definir cuáles son los
componentes concretos del sistema de información (usuarios, contexto, etc.), definir qué se espera que el sistema
haga y qué datos en concreto se requerirán para su funcionamiento.
3. Diseño conceptual: Una vez que se tiene la especificación inicial del sistema, un profesional (o un grupo) ex-
perto en bases de datos o un analista puede empezar a realizar el esquema conceptual del sistema. Éste es una
visión de alto nivel del sistema que registra qué información se va a almacenar, qué formato va a tener y cómo se
relaciona con otra información. Este esquema conceptual también especifica los derechos de acceso de grupos y
programas. Para las bases de datos relacionales se suele utilizar el modelo entidad relación para proporcionar una
visión conjunta del sistema. En algunos casos, sobretodo si los datos son muy heterogéneos, se puede decidir
realizar el modelo utilizando lenguajes de modelado orientados a objetos como UML.
4. Elección de SGBD: No es una fase realmente, porque este paso se suele pensar antes del desarrollo de una base
de datos en concreto o se decide para ser utilizado con varios fines. No obstante, si la organización dispusiera de
varios, o de ninguno, con lo que tendría que elegir, esta elección se limita por muchas razones: monetarias, cono-
cimientos disponibles de los profesionales informáticos, decisiones de gestión y un número importante de otros
factores, específicos a cada organización. De todos los sistemas disponibles, se intentará encontrar el sistema más
apropiado para la base de datos que se desea diseñar. Las siguientes fases se podrán realizar ya acordes con las
capacidades y limitaciones del sistema elegido.
5. Diseño lógico: Durante esta fase del proceso, se toma el esquema producido en el diseño conceptual y se con-
vierte al modelo sobre el que trabaja el SGBD. Esta fase nos acerca ya al sistema final, ya que se tiene un modelo
que se adapta al SGBD donde funcionará.
6. Diseño Físico: En esta fase, se centran los esfuerzos en la implementación práctica de la base de datos. En esta
fase se incluyen las pruebas de hardware, el cálculo del nivel de estrés (carga) que el sistema puede aguantar. Esto
54
Base de Datos
es importante, especialmente si los datos van a accederse frecuentemente y pueden existir picos. Además los
discos que albergan los datos más usados tienen un acceso más regular y por tanto aumenta su probabilidad de
fallo. Este tipo de información, junto con otra información crítica, debe mantenerse distribuida y salvaguardada
mediante el uso de mirrors o de organizaciones de pilas de discos. En esta fase también se estudian los índices y
otras estructuras de organización física más apropiadas para optimizar el rendimiento.
7. Implementación: una vez realizados todos los pasos anteriores, debidamente documentados, se puede pasar
a implementar el sistema. Los detalles de implementación dependen en gran medida del SGBD, de los lenguajes
de programación de las aplicaciones, de una serie de estándares y protocolos que puedan estar utilizando tanto
el SGBD como las aplicaciones y otros muchos factores. Cuanto más detallada y clara es la especificación inicial,
más rápida será la implementación. Al contrario, si las primeras fases se han descuidado o han venido marcadas
por las prisas, la fase de implementación se alargará y el sistema estará lleno de parches y de modificaciones so-
bre modificaciones, degradándose su eficacia y su seguridad. Además, las modificaciones, como en casi cualquier
desarrollo de un proyecto, son más costosas cuanto más tarde se hagan.
8. Conversión y carga de datos y pruebas: en el caso de una migración se debe hacer una conversión de los datos
existente en fuentes de información previas o anteriores a la base de datos que se acaba de implementar. Si no
existe migración se deberá realizar una primera carga de datos ficticios o reales para realizar pruebas más com-
pletas del sistema.
9. Ajuste de rendimiento: Una vez el sistema comienza a estar operativo y se tienen datos (aunque en esta fase
todavía pueden ser ficticios), se puede comenzar a ajustar el rendimiento, utilizando y simulando las cargas que
se prevén en el funcionamiento normal del sistema.
Una vez que la base de datos adquiere un volumen de datos real importante (ya sea por migración de otra base
de datos, la cual se debería diseñar cuidadosamente, o por inserción de nuevos datos), es cuando realmente se
empieza a evaluar si las decisiones de diseño fueron correctas. Evidentemente, casi todos los sistemas se revisan
y se amplían, pero estas modificaciones deben seguir los pasos anteriores a partir de aquél que haya motivado
el cambio o extensión (requerimientos, conceptual, lógico, físico o de rendimiento). En estos cambios hay que
tener en cuenta los costes a medio plazo, ya que pequeños retoques baratos a corto plazo pueden no resolver el
problema a medio y largo plazo.
Modelo de datos
Los modelos se utilizan en todo tipo de ciencias. Su finalidad es la de simbolizar una parte del mundo real de for-
ma que sea más fácilmente manipulable. En definitiva es un esquema mental (conceptual) en el que se intentan
reproducir las características de una realidad específica.
En el caso de los modelos de datos, lo que intentan reproducir es una información real que deseamos almacenar
en un sistema informático.
Se denomina esquema a una descripción específica en términos de un modelo de datos. El conjunto de datos
representados por el esquema forma la base de datos.

Gráfico 17 - Clasificación de los modelos de datos.
55
En Gráfico 17 aparecen los distintos esquemas que llevan desde el mundo real a la base de datos física. Como se
ve aparecen varios esquemas intermedios. Los que están más a la izquierda se alejan más de las características
físicas. Los elementos de ese esquema son:
1. Mundo real. Contiene la información tal cual la percibimos como seres humanos. Es el punto de partida.
2. Esquema conceptual. Representa el modelo de datos de forma independiente del DBMS que se utilizará.
3. Esquema canónico (o de base de datos). Representa los datos en un formato más cercano al de la maquina.
4. Esquema interno. Representa los datos según el modelo concreto de un sistema gestor de bases de datos
(por ejemplo Oracle).
5. Base de datos física. Los datos tal cual son almacenados en disco.
Características del modelado

1. Es el proceso de analizar los aspectos de interés para una organización y la relación que tienen unos con
otros.
2. Resulta en el descubrimiento y documentación de los recursos de datos del negocio.
3. El modelado hace la pregunta “ ¿Qué? “ en lugar de “ ¿Cómo? “, ésta última orientada al procesamiento de
los datos.
4. Es una tarea difícil, bastante difícil, pero es una actividad necesaria cuya habilidad solo se adquiere con la
experiencia.
Diferencias entre el diseño lógico y conceptual.

El modelo conceptual es independiente del DBMS que se vaya a utilizar. El lógico depende de un tipo de SGBD
en particular.
El modelo lógico está más cerca del modelo físico, el que utiliza internamente la maquina.
El modelo conceptual es el más cercano al usuario, el lógico es el encargado de establecer el paso entre el modelo
conceptual y el modelo físico del sistema.
Ejemplos de modelos conceptuales son:

1. Modelo de entidad-relación.
2. Modelo orientado a objetos.
3. Modelo de datos semántico.
4. Modelo de datos funcional.
Ejemplos de modelos lógicos son:

1. Modelo relacional.
2. Modelo de red.
3. Modelo Jerárquico.
Modelos conceptuales
Modelo de datos entidad-relación (MER)
Está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados entida-
des, y de relaciones entre estos objetos.
• Una entidad es una «cosa» u «objeto» en el mundo real que es distinguible de otros objetos.
• Los atributos describen propiedades que posee cada miembro de un conjunto de entidades.
• Una relación es una asociación entre varias entidades.
56
Base de Datos
Gráfico 18
Modelo entidad relación

Modelo orientado a objetos
Desde la aparición de la programación orientada a objetos (POO u OOP) se empezó a pensar en bases de datos
adaptadas a estos lenguajes. La programación orientada a objetos permite cohesionar datos y procedimientos,
haciendo que se diseñen estructuras que poseen datos (atributos) en las que se definen los procedimientos (ope-
raciones) que pueden realizar con los datos. En las bases orientadas a objetos se utiliza esta misma idea.
A través de este concepto se intenta que estas bases de datos consigan arreglar las limitaciones de las relaciona-
les. Por ejemplo el problema de la herencia (el hecho de que no se puedan realizar relaciones de herencia entre
las tablas), tipos definidos por el usuario, disparadores (triggers) almacenables en la base de datos, soporte multi-
media. Se supone que son las bases de datos de tercera generación (la primera fue las bases de datos en red y la
segunda las relacionales), lo que significa que el futuro parece estar a favor de estas bases de datos. Pero siguen
sin reemplazar a las relacionales, aunque son el tipo de base de datos que más está creciendo en los últimos años.
Su modelo conceptual se suele diseñar en UML y el lógico actualmente en ODMG (Object Data Management
Group, grupo de administración de objetos de datos, organismo que intenta crear estándares para este modelo).
Gráfico 19
Modelo orientado a objetos
57
Modelo de datos semántico

Un modelo de datos semánticos es una técnica para definir el significado de los datos en el contexto de sus inte-
rrelaciones con otros datos. Un modelo de datos semántica es una abstracción que define cómo se almacenan los
símbolos se relacionan con el mundo real.
Gráfico 20
Modelo semántico.
Modelos Lógicos
Modelo relacional
El modelo relacional para la gestión de una base de datos es un modelo de datos basado en la lógica de predi-
cados y en la teoría de conjuntos. Es el modelo más utilizado en la actualidad para modelar problemas reales y
administrar datos dinámicamente.
Gráfico 21 - Modelo relacional.
58
Base de Datos
Modelo jerárquico
Era utilizado por los primeros SGBD, desde que IBM lo definió para su IMS (Information Management System,
Sistema Administrador de Información) en 1970. Se le llama también modelo en árbol debido a que utiliza una
estructura en árbol para organizar los datos.
La información se organiza con un jerarquía en la que la relación entre las entidades de este modelo siempre es
del tipo padre / hijo. De esta forma hay una serie de nodos que contendrán atributos y que se relacionarán con
nodos hijos de forma que puede haber más de un hijo para el mismo padre (pero un hijo sólo tiene un padre).
Los datos de este modelo se almacenan en estructuras lógicas llamadas segmentos. Los segmentos se relacionan
entre sí utilizando arcos.
La forma visual de este modelo es de árbol invertido, en la parte superior están los padres y en la inferior los hijos.
Gráfico 22
Modelo jerárquico.
Este esquema está en absoluto desuso ya que no es válido para modelar la mayoría de problemas de bases de
datos.
Modelo de Red
Es un modelo que ha tenido una gran aceptación (aunque apenas se utiliza actualmente). En especial se hizo po-
pular la forma definida por Codasyl a principios de los 70 que se ha convertido en el modelo en red más utilizado.
El modelo en red organiza la información en registros (también llamados nodos) y enlaces. En los registros se
almacenan los datos, mientras que los enlaces permiten relacionar estos datos. Las bases de datos en red son
parecidas a las jerárquicas sólo que en ellas puede haber más de un padre.
En este modelo se pueden representar perfectamente cualquier tipo de relación entre los datos (aunque el Co-
dasyl restringía un poco las relaciones posibles), pero hace muy complicado su manejo.
Gráfico 23 - Modelo de red.
59
Resumen tema 6
Modelo de datos
Los modelos se utilizan en todo tipo de ciencias. Su finalidad es la de simbolizar una parte del mundo real de for-
ma que sea más fácilmente manipulable. En definitiva es un esquema mental (conceptual) en el que se intentan
reproducir las características de una realidad específica.
En el caso de los modelos de datos, lo que intentan reproducir es una información real que deseamos almacenar
en un sistema informático.
Diferencias entre el modelo lógico y el conceptual.

El modelo conceptual es el más cercano al usuario, el lógico es el encargado de establecer el paso entre el modelo
conceptual y el modelo físico del sistema.
Distintos tipos de modelos:
Ejemplos de modelos conceptuales son:

• Modelo de entidad-relación.
• Modelo orientado a objetos.
• Modelo de datos semántico.
• Modelo de datos funcional.
Ejemplos de modelos lógicos son:

• Modelo relacional.
• Modelo de red.
• Modelo Jerárquico.
Autoevaluación
1. ¿Qué entiende por modelo de datos?
2. ¿Cuál es la diferencia de los modelos conceptuales y lógicos?
3. ¿Qué es un modelo de entidad-relación?
4. ¿Qué es un modelo orientado a objetos?
5. ¿Explique un modelo orientado a objetos?
6. ¿Explique un modelo relacional?
7. ¿Explique un modelo de red?
8. ¿Explique un modelo Jerárquico?
Investigación
1. Investigue donde se usaba el modelo de red.
2. Averigüe cual de los modelos conceptúales cual es el más usado.
3. Lea de Sistemas de base de datos – conceptos fundamentales – Elmasri - Navathe. Pearson educación. Capitulo
2 Concepto y arquitectura de los sistemas de base de datos.
4. Lea de Sistemas de base de datos – conceptos fundamentales – Elmasri - Navathe. Pearson educación. Capitulo
10 Modelo de datos y sistemas convencionales.
60
Unidad 3

4. SQL, DDL y SML
Tema Nº 7
Modelo entidad relación
Introducción
Fue ideado por Peter Chen en los años 1976 y 1977 a través de dos artículos. Se trata de un modelo que sirve para
crear esquemas conceptuales de bases de datos. De hecho es prácticamente un estándar para crear esta tarea.
Se le llama modelo E/R e incluso EI (Entidad / Interrelación). Sus siglas más populares son las E/R por qué sirven
para el inglés y el español.
Inicialmente (en la propuesta de Chen) sólo se incluían los conceptos de entidad, relación y atributos. Después se
añadieron otras propuestas (atributos compuestos, generalizaciones,...) que forman el llamado modelo entidad
relación extendido (se conoce con las siglas ERE)
Objetos del modelo

1. Entidad
2. Relación
3. Atributo
4. Dominio
Entidad
Se trata de cualquier objeto u elemento (real o abstracto) acerca del cual se pueda almacenar información en la
base de datos. Ejemplos de entidades son Pedro, la factura número 32456, el coche patente URS698.
Una entidad no es un propiedad concreta sino un objeto que puede poseer múltiples propiedades (atributos).
Conjunto de entidades
Las entidades que poseen las mismas propiedades forman conjuntos de entidades.
Ejemplos de conjuntos de entidades son los conjuntos: personas, facturas, coches,...
Gráfico 24 - Entidades.

En la actualidad se suele llamar entidad a lo que anteriormente se ha definido como conjunto de entidades. De
este modo hablaríamos de la entidad PERSONAS. Mientras que cada persona en concreto sería una ocurrencia o
un ejemplar de la entidad persona.
62
Base de Datos
Representación gráfica de las entidades

En el modelo entidad relación los conjuntos de entidades se representan con un rectángulo dentro del cual se
escribe el nombre de la entidad:
Gráfico 25
Representación de la entidad persona.
Tipos de entidades.
• Regulares. Son las entidades normales que tienen existencia por sí mismas sin depender de otras. Su repre-
sentación gráfica es la indicada arriba
• Débiles. Su existencia depende de otras. Por ejemplo la entidad tarea laboral sólo podrá tener existencia si
existe la entidad trabajo. Las entidades débiles se presentan de esta forma:
Gráfico 26
Representación de entidad débil.
Relaciones
¿Qué es una relación?

Representan asociaciones entre entidades. Es el elemento del modelo que permite relacionar en sí los datos del
modelo. Por ejemplo, en el caso de que tengamos una entidad personas y otra entidad trabajos. Ambas se reali-
zan ya que las personas trabajan y los trabajos son realizados por personas:
Gráfico 27
Ejemplo de relación.
63
Representación gráfica
La representación gráfica de las entidades se realiza con un rombo al que se le unen líneas que se dirigen a las
entidades, las relaciones tienen nombre (se suele usar un verbo). En el ejemplo anterior podría usarse como nom-
bre de relación, trabajar:
Gráfico 28
Ejemplo de relación
Grado de un tipo de relación

Es el número de entidades que participan en el tipo de relación:
• Binaria: grado 2 (el más frecuente)
• Ternaria: grado 3
• Reflexiva (o recursiva): grado 1
Gráfico 29
Relación Binaria o de grado 2
Gráfico 30
Relación Terciaria o de grado 3
Gráfico 31
Relación Doble
64
Base de Datos
Gráfico 32
Relación reflexiva o de grado 1
Papel o rol
Es la función que cada uno de los tipos de entidad realiza en la interrelación, el nombre del papel en el arco que
une a cada tipo de entidad con la interrelación.

Gráfico 33 – Papel o rol de una relación.
Correspondencia de cardinalidades
Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la correspondencia de
cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada. Dado un con-
junto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser:
• Uno a Uno: Una entidad de A se relaciona únicamente con una entidad en B y viceversa.
• Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se
relaciona con una única entidad en A.
• Varios a Uno: Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se
puede relacionar con 0 o muchas entidades en A.
• Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa.
65
Ejemplificación:
Relación 1 a1

Gráfico 34 - correspondencia 1:1.
Relación uno a uno (1:1) el actor Darin actuó solo en El ecreto de sus ojos y no en Rocky ni en Titanic. Mientras
desde la vista película no solo actuo Darin, no Satallone ni Dicaprio. Lo mismo para los otros actores y películas,
solo le corresponde un actor por película y una película por actor.
Relación 1 a muchos
Gráfico 35 - correspondencia 1:M.
Relación uno a muchos (1:M) los animales vivíparos son el perro, el caballo y el gato, no es como el ejemplo ante-
rior de actor película en este cado Reproducción tiene más de un animal. Y a la inversa el caballo es vivíparo y no
ovíparo, la relación en este sentido es única.
66
Base de Datos
Relación muchos a muchos

Gráfico 36 - correspondencia M:N.
Relación muchos a muchos (M:N) José trabaja en más de un proyecto, en los proyectos 1 y 2, pero no trabaja solo
en esos proyecto tiene colaboradores.
Cardinalidad
Indica el número de relaciones en las que una entidad puede aparecer. Se anota en términos de:
• Cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá cada ejemplar de la
entidad (el valor que se anota es de cero o uno)
• Cardinalidad máxima. Indica el número máximo de relaciones en las que puede aparecer cada ejemplar de
la entidad (puede ser uno o muchos)
En los esquemas entidad / relación la cardinalidad se puede indicar de muchas formas.

Actualmente una de las más populares es esta:
Gráfico 37
Notación cardinalidades
mínimas y máximas.
67
Gráfico 38
Ejempo Cardinalidades
mínimas y máximas.

A veces en las líneas de la relación se indican roles. Los roles representan el papel que juega una entidad en una
determinada relación. Ejemplo:
Gráfico 39
Cardinalidades mínimas
y máximas y roles.

Gráfico 40 - Cardinalidades mínimas y máximas norma MPM1999.
68
Base de Datos
Atributos
Propiedad o característica de una entidad.
Una entidad particular es descrita por los valores de sus atributos:
Ejemplo: la entidad película tiene los atributos titulo, género, nacionalidad, año estreno.

Gráfico 41 – Entidad y atributos.
Clasificación de atributos
1. Simples o Compuestos
2. Almacenados o Derivados
3. Monovalorados o Multivalorados
4. Opcionales
Atributos Simples
Atributos simples: no son divisibles son atómicos.
Gráfico 42
Atributo simple.

Atributos Compuesto
Atributos compuestos: pueden dividirse en otros con significado propio.
Gráfico 43
Atributo compuesto.
69
Atributos Derivados
Valor calculado a partir de otra información ya existente (atributos, entidades relacionadas). Atributo edad deri-
vado del valor de otro atributo fecha_nacimiento.
Edad [de EMPLEADO], cálculo a partir de fecha_naciminto
Atributos Almacenados
Dato no calculado.
fecha_nacimiento [de EMPLEADO]
Atributos Monovalorado
El atributo sólo toma un valor para cada entidad.
fecha_naciminto [EMPLEADO]
año_estreno [PELICULA]
Atributos Multivalorado
El atributo toma más de un valor para la misma entidad.
teléfono [EMPLEADO]
Atributos Opcionales o nulos

Se desconoce el valor de un atributo para cierta entidad.
Atributos Clave
Atributo Identificador Primario de un tipo de entidad es clave univoca para identificar dicha entidad.
Ej: Para la entidad ALUMNO el atributo DNI es univoco.
Atributo Identificador Alternativo de un tipo de entidad puede tener más de una clave univoca candidata o al-
ternativa.
Ej: Para la entidad COLECTIVO tengo varios atributos unívocos.
Interno
Dominio
Numero de motor.
Numero de Chasis.
Atributo Identificador Compuesto de un tipo de entidad es un cuando está compuesto por más de un atributo
como clave univoca.
Ej: en una agencia de turismo el atributo paquete está compuesto por el hotel y los días. El paquete CAMCUN
- Hotel Suites Cancún Center – 7 días, es diferente al CAMCUN - Hotel Suites Cancún Center – 10 días. Son dos
paquetes diferentes.
70
Base de Datos

Gráfico 44 – Atributos notaciones.
Dominio
• Las distintas propiedades o características de un tipo de entidad o de interrelación toman valores para cada
ocurrencia de estos.
• El conjunto de los posibles valores que puede tomar una cierta característica se denomina dominio.
• Para saber si un valor pertenece a un dominio determinado comprendemos que cumple un predicado que
este lleva siempre asociado.
• Ej:el valor ‘ingles’ se toma del dominio Idiomas y cumple con el predicado de ser uno de los idiomas posibles
del conjunto { ‘frances’ ; ’ingles’ }
Resumen tema 7
Objetos del modelo
• Entidad
• Relación
• Atributo
• Dominio
Entidad
Entidad: objeto u elemento (real o abstracto) acerca del cual se pueda almacenar información en la base de datos.
Entidades Regulares. Son las entidades normales que tienen existencia por sí mismas sin depender de otras.
Entidades Débiles. Su existencia depende de otras.
Relación
Representan asociaciones entre entidades. Es el elemento del modelo que permite relacionar en sí los datos del
modelo.
71
Grado de relación: es el número de entidades que participan en el tipo de relación:
Papel o rol: función que cada uno de los tipos de entidad realiza en la interrelación, el nombre del papel en el arco
que une a cada tipo de entidad con la interrelación.
Tipo de correspondencia: número máximo de ocurrencias de cada tipo de entidad que pueden intervenir en una
ocurrencia del tipo interrelación que se está tratando.
Cardinalidad: número de relaciones en las que una entidad puede aparecer. Se anota en términos de:
• Cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá cada ejemplar de la
entidad (el valor que se anota es de cero o uno)
• Cardinalidad máxima. Indica el número máximo de relaciones en las que puede aparecer cada ejemplar de
la entidad (puede ser uno o muchos)
Atributos
Propiedad o característica de una entidad.
Una entidad particular es descrita por los valores de sus atributos.
Clasificación de atributos.
4. Opcionales
Dominio
El conjunto de los posibles valores que puede tomar una cierta característica se denomina dominio.
Autoevaluación.
1. ¿Cuáles son los componentes del modelo entidad relación?

2. Si se modela las propiedades de una entidad que se está modelando. Ejemplo dirección, teléfono y fecha
de nacimiento de empleado.
3. De los alumnos de un colegio se tomo como atributo identificador primario el número de legajo que uni-
voco, también se guarda el DNI. Este último qué tipo de atributo seria en este contexto.
4. En una agencia de micros de media distancia la clave univoca para identificar los viajes son el interno de
micro, el destino, la fecha y el chofer; debido a que van rotando todos los componentes. ¿Esta clave univo-
ca como estaría formada?
5. Si el atributo antigüedad de la entidad empleado la calculo con el atributo fecha de ingreso. ¿Qué tipos de
atributo son estos últimos?
6. Qué diferencia existe entre el atributo fecha de nacimiento de la entidad empleado, va tomar un único
valor y el atributo estudios cursados.
7. Si tengo una relación DICTA entre la entidad PROFESOR y MATERIA, y me dicen que el profesor solo puede
dictar una materia y cada materia puede ser dictada por un solo profesor ¿Qué tipo cardinalidad tiene?
8. ¿Cuál sería el dominio del atributo VOCALES de la entidad LETRA?
Investigación
1. Indague los diferentes tipos de notaciones de MER.
2. Lea de Concepción y diseño de base datos del Modelo E/R al Modelo Relacional - Adoración de Miguel,
Mario Piattini. Ra-ma. Capitulo 8 Modelo entidad relación.
3. Lea de Organización de base de datos – James Martin. Prentice Hall. El capitulo 5 Entidades y Atributos.
72
Base de Datos
Tema Nº 8
Modelo entidad relación extendido
En el modelo entidad relación extendido aparecen nuevos tipos de relaciones. Son las relaciones ISA (es un) y las
entidades débiles.
Relaciones ISA o de herencia

Son relaciones que indican tipos de entidades, es decir tendremos entidades que son un (is a, en inglés) tipo de
entidad.
Se utilizan para unificar entidades agrupándolas en una entidad más general (generalización) o bien para dividir
una entidad general en entidades más específicas (especificación). Aunque hoy en día a todas se las suele llamar
generalización e incluso relaciones de herencia.
Se habla de generalización si inicialmente partimos de una serie de entidades que al estudiarlas en detalle descu-
brimos que todas ellas pertenecen al mismo conjunto, que será el que determine una nueva entidad. En la gene-
ralización las entidades son totalmente heterogéneas, es decir, los atributos son diferentes. La entidad general se
llama superentidad las otras se denominan subentidades. En la superentidad se colocan los atributos comunes a
todas las subentidades. Y normalmente se la coloca una clave principal distinta de las subentidades La especia-
lización ocurre cuando partimos de una entidad que podemos dividir en subentidades para detallar atributos
que varían en las mismas. Comparten clave con la superentidad y los atributos de la superclase se heredan en las
subclases.
En la práctica se manejan casi igual ambas; la forma de representar una Isa es:
Gráfico 45 – Relación ISA.
La diferencia fundamental es que en la generalización cada ejemplar de la superentidad está relacionado seguro
al menos con un ejemplar de una subentidad. Es lo que se conoce como jerarquía total (se explica más adelante).
De modo que en este caso la cardinalidad de la superentidad en la relación ISA será (1,1) mientras que en general
en las subentidades será de 0,1 (hay casos de (0,n),(1,1) o (1,n) pero son muy raros).
En la especialización sin embargo, puede haber ejemplares de la superentidad que no se realización con ninguna
subentidad (jerarquía parcial) y por ello se marca una sistemas gestores de bases de datos gestión y diseño de
bases datos cardinalidad (0,1) en la superentidad. No obstante podría haber especializaciones con cardinalidad
(1,1); por ello en la práctica lo que importa es saber si la jerarquía es total o parcial y no saber so hay generaliza-
ción o especialización.
73
Como se comentó antes, la cuestión de si es una especialización o generalización se suele distinguir por las cla-
ves; si se comparte clave entre la superentidad y sus descendientes, se habla de especialización; de otro modo se
habla de generalización (aunque esto es muy rebatible, en la práctica suele ser la única forma de distinguir ambos
conceptos en el esquema ya realizado; sólo hay una certeza y es que si la cardinalidad es 0,1 en la superentidad,
con seguridad tenemos una especialización).
De cualquier modo, la cuestión de si tenemos una generalización o una especialización no es tan importante
como el hecho de no errar las cardinalidades, unas malas cardinalidades podrían provocar que el siguiente es-
quema del sistema (el esquema lógico) falle (y con él los demás esquemas y por lo tanto la base de datos en sí).

Gráfico 46 – Ejemplo de relación ISA.
Con atributos el esquema sería:
Gráfico 47 – Especialización, la clave de la superentidad es clave de las subentidades.
74
Base de Datos
En la especialización anterior (lo es porque la clave la tiene la superentidad) los profesores, ayudantes y técnicos
heredan el atributo id_personal y el nombre, el resto son atributos propios sólo de cada entidad (departamento
pertenece sólo a los profesores, en este ejemplo).
Gráfico 48 – Generalización. La clave de la superentidad no es clave de las subentidades.
En el Gráfico anterior artículo es una generalización de los discos, libros y artículos de merchandising, se utiliza
una clave distinta para esta entidad. Incluso en este caso podría haber discos o libros o merchandising que no
están relacionados con los artículos (la cardinalidad de artículos es 0,1).
En las relaciones ISA (y también en otros tipos de relaciones) se puede indicar el hecho de que cada ejemplar sólo
puede participar en una de entre varias ramas de una relación. Este hecho se marca con un arco entre las distintas
relaciones. En las relaciones ISA se usa mucho, por ejemplo:

Gráfico 49 – Relación ISA con obligatoriedad
75
Tipos relaciones ISA

En el ejemplo, el personal sólo puede ser o ayudante, o profesor o técnico; una y sólo una de las tres cosas (es por
cierto la forma más habitual de relación ISA).
Gráfico 50
Relación ISA solapada total.
Gráfico 51
Relación ISA solapada parcial.
Gráfico 52
Relación ISA exclusiva total.
Gráfico 53
Relación ISA exclusiva parcial.
76
Base de Datos
Relaciones de jerarquía solapada. Indican que un ejemplar de la superentidad puede relacionarse con más de una
subentidad (el personal puede ser profesor y ayudante). Ocurren cuando no hay dibujado un arco de exclusividad.
Relaciones de jerarquía exclusiva. Indican que un ejemplar de la superentidad sólo puede relacionarse con una
subentidad (el personal no puede ser profesor y ayudante). Ocurren cuando hay dibujado un arco de exclusividad.
Relaciones de jerarquía parcial. Indican que hay ejemplares de la superentidad que no se relacionan con ningu-
na subentidad (hay personal que no es ni profesor, no ayudante ni técnico). Se indican con cardinalidad mínima
de cero en la superentidad.
Relaciones de jerarquía total. Indican que todos los ejemplares de la superentidad se relacionan con alguna
subentidad (no hay personal que no sea ni profesor, ni ayudante ni técnico). Se indican con cardinalidad mínima
de uno en la superentidad.
Todos los posibles ejemplos de relaciones ISA atendiendo a la cardinalidad son los expuestos en los gráficos 45
al 48 inclusive.
Entidades débiles
Ya se ha comentado antes que una entidad débil es aquella cuya existencia depende de otra. Ahora vamos a
clarificar más estas entidades. Efectivamente ocurren cuando hay una entidad más fuerte de la que dependen.
Lógicamente tienen relación con esa entidad. En la forma clásica se representaría de esta forma:
Gráfico 54 – Relación candidata a entidad débil.
En el diagrama la relación entre las tareas y los trabajos es 1 a n (cada trabajo se compone de n tareas). Una tarea
obligatoriamente está asignada a un trabajo, es más no tiene sentido hablar de tareas sin hablar del trabajo del
que forma parte.
Hay incluso (aunque no siempre) una dependencia de identificación ya que las tareas se identifican por un número
de tarea y el número de trabajo al que se asignan. Esto es un síntoma definitivo de que se trata de una entidad débil.
77
Todas las entidades débiles tienen este tipo de relación 1 a n con respecto a la entidad fuerte de la que depende
su existencia, por eso se representan de esta otra forma:
Gráfico 55 – Entidad débil relacionada con su entidad fuerte.
No hace falta dibujar el rombo de la relación ni la cardinalidad, se sobreentiende el tipo y cardinalidad (1 a n) que
posee. No siempre identificador de la entidad débil incluye el identificador de la entidad fuerte.
Control de redundancias
Los esquemas E/R, y en general en los de cualquier modelo de datos es necesario evitar las redundancias para no
tener problemas de inconsistencias de la representación.
Un elemento de un esquema es redundante si puede ser eliminado sin pérdida de semántica.
Existen dos formas principales de redundancia:

• En los atributos (atributos derivados o calculados): aunque son redundantes, no dan lugar a inconsistencias
siempre que en el esquema se indique su condición de derivados y la fórmula mediante la que han de ser
calculados.
• En las interrelaciones (también llamadas interrelaciones derivadas): una interrelación es redundante si su

eliminación no implica pérdida de semántica porque existe la posibilidad de realizar la misma asociación de
ejemplares por medio de otras interrelaciones.
Para ello es condición necesaria pero no suficiente que forme parte de un ciclo. Hay que estudiar detenidamente
los ciclos en el diagrama E/R. La existencia de un ciclo no implica la existencia de interrelaciones redundantes.
Para que una interrelación pueda ser eliminada por redundante se tiene que cumplir:
• Que exista un ciclo

• Que las interrelaciones que componen el ciclo sean equivalentes semánticamente
• Que después de eliminar la interrelación se puedan seguir asociando los ejemplares de las dos entidades
que estaban interrelacionadas
• Que la interrelación no tenga atributos o que éstos puedan ser transferidos a otro elemento del esquema a
fin de no perder su semántica.
78
Base de Datos
Gráfico 56
Ciclo con tipo de
interrelación redundante.
Gráfico 57
Ciclo de interrelaciones
sin redundancia.
Pasos para el diseño:
1. Encontrar entidades (conjuntos de entidades).

2. Identificar atributos de las entidades.
3. Buscar identificadores.
4. Especificar las relaciones y cardinalidades.
5. Identificar entidades débiles.
6. Especializar y generalizar entidades donde sea posible.
79
Resumen tema 8
En el modelo entidad relación extendido aparecen nuevos tipos de relaciones. Son las relaciones ISA (es un) y las
entidades débiles.
Relaciones ISA
entidad.
Se utilizan para unificar entidades agrupándolas en una entidad más general (generalización) o bien para dividir
una entidad general en entidades más específicas (especificación). Aunque hoy en día a todas se las suele llamar
generalización e incluso relaciones de herencia.
Tipos de relaciones ISA

Relaciones de jerarquía solapada. Indican que un ejemplar de la superentidad puede relacionarse con más de
una subentidad. Ocurren cuando no hay dibujado un arco de exclusividad.
subentidad. Ocurren cuando hay dibujado un arco de exclusividad.
Relaciones de jerarquía parcial. Indican que hay ejemplares de la superentidad que no se relacionan con nin-
guna subentidad. Se indican con cardinalidad mínima de cero en la superentidad.
subentidad. Se indican con cardinalidad mínima de uno en la superentidad.
Entidades débiles
Ya se ha comentado antes que una entidad débil es aquella cuya existencia depende de otra. Ahora vamos a
clarificar más estas entidades. Efectivamente ocurren cuando hay una entidad más fuerte de la que dependen.
Lógicamente tienen relación con esa entidad.
Todas las entidades débiles tienen este tipo de relación 1 a n con respecto a la entidad fuerte de la que depende
su existencia.
No hace falta dibujar el rombo de la relación ni la cardinalidad, se sobreentiende el tipo y cardinalidad (1 a n) que
posee. No siempre identificador de la entidad débil incluye el identificador de la entidad fuerte.
Control de redundancias
Los esquemas E/R, y en general en los de cualquier modelo de datos es necesario evitar las redundancias para no
tener problemas de inconsistencias de la representación.
Un elemento de un esquema es redundante si puede ser eliminado sin pérdida de semántica.
Existen dos formas principales de redundancia:
• En los atributos (atributos derivados o calculados): aunque son redundantes, no dan lugar a inconsistencias
siempre que en el esquema se indique su condición de derivados y la fórmula mediante la que han de ser
calculados.
• En las interrelaciones (también llamadas interrelaciones derivadas): una interrelación es redundante si su

eliminación no implica pérdida de semántica porque existe la posibilidad de realizar la misma asociación de
ejemplares por medio de otras interrelaciones.
80
Base de Datos
Autoevaluación
1. ¿Que son las relaciones ISA?
2. Si tengo las entidades libro y ejemplar con la interrelación tiene.
SI no tengo ningún libro

no tengo ningún ejemplar.
¿Qué tipo de entidades son?
3. Estamos diseñando una base de datos para el área de recursos humanos de una empresa de services de televi-
sores, solo guardamos los datos de los empleados, DNI, nombre, apellido, dirección, teléfono y fecha de ingre-
so. Dentro de los empleados tenemos técnicos, chóferes y maestranza. Para los técnicos se necesita agregar a
los datos descriptos anteriormente el estudio cursado, mientras que para los chóferes el número de licencia de
conducir. Para el personal de maestranza el horario.
Preguntas
a. ¿Qué tipo de relación es si el personal puede ser técnico y chofer?
b. ¿Qué tipo de relación es si el personal no puede ser técnico y chofer?
c. ¿Qué tipo de relación es si hay personal que no es ni técnico, ni chofer ni maestranza?
d. ¿Qué tipo de relación es si no hay personal que no es ni técnico, ni chofer ni maestranza?
Investigación
1. Lea de Concepción y diseño de base datos del Modelo E/R al Modelo Relacional - Adoración de Miguel, Mario
Piattini. Ra-ma. Capitulo 8 Modelo entidad relación.
2. Lea Diseño de base de datos Problemas resueltos - Adoración de Miguel, Paloma Martínez, Elena Castro, Dolo-
res Cuadra, Ana Iglesias, Carlos Nieto. Ra-ma. Capitulo 1.
81
Tema Nº 9
Diseño de un modelo de entidad relación
Ejercicio 1
Identificar entidades y relaciones de la siguiente situación:
Tenemos una universidad, en la que hay varios cursos. Cada curso está dirigido por un profesor, el cual puede
dirigir varios cursos. Sólo se permite que un alumno se matricule de un curso.
Identificamos los sustantivos y los verbos que los unen.
Tenemos una universidad, en la que hay varios cursos. Cada curso está dirigido por un profesor, el cual puede
dirigir varios cursos. Sólo se permite que un alumno se matricule de un curso.
Entidades Interrelaciones Entidad/interrelación

Profesor Dirige entre Profesor y Curso
Curso Matricula entre Curso y Alumno
Alumno
Cuadro 2 – Lista de entidades y relaciones.
Ejercicio 2
Supongamos el siguiente universo de discurso sobre municipios, viviendas y personas. Cada persona puede
habitar una vivienda y estar empadronado en un único municipio, pero puede ser propietaria de varias viviendas.
Nos interesa también conocer las personas que dependen del cabeza de familia (C.F.). Se indicarán los supuestos
semánticas que se consideren oportunos para justificar todas las decisiones de diseño.
Discusión del enunciado

1er Paso: Elaborar las listas de conceptos candidatos a ser entidades e interrelaciones e indicar también los con-
ceptos que no se sabe como catalogar.
Para ello nos ayudamos prestando atención a los sustantivos y los verbos que los unen.
Cada persona solo puede habitar una vivienda y estar empadronada en un municipio, pero puede ser propie-
taria de varias viviendas. Nos interesa también conocer las personas que dependen del cabeza de familia (C.F.).
Las listas obtenidas son:
Entidades Interrelaciones Entidad/interrelación

MUNICIPIO Habita entre PERSONA y VIVIENDA
VIVIENDA Empadrona entre PERSONA y MUNICIPIO
PERSONA Propiedad entre PERSONA y VIVIENDA
Cuadro 3 – Lista de conceptos candidatos a ser entidades.
82
Base de Datos
2º Paso: Construir una matriz de entidades y entidades para representar todas las interrelaciones junto con su tipo
de correspondencia. Para ello iremos analizando los supuestos semánticas explícitamente representados en el
enunciado, así como los que están implícitos o son de sentido común.
a) Supuestos no dados en el enunciado.

• Una vivienda puede ser habitada por muchas personas.
• Una vivienda puede ser propiedad de muchas personas.
• Una persona solo puede tener un cabeza de familia y un cabeza de familia puede serlo de varias personas.
• Un municipio puede tener muchas viviendas y una vivienda pertenece a un solo municipio.
Persona Municipio Vivienda

Persona C.F. (1:N) Empadronada (1:N) Habita (1:N)
Propiedad (N:M)
Municipio X ---- Esta_en (N:1)
Vivienda X X -----
Cuadro 4 – Lista de conceptos candidatos a ser entidades.
3er Paso: Obtener una versión preliminar del esquema entidad relación. A continuación se muestra una primera
versión del esquema E/R correspondiente a los supuestos del enunciado.

Gráfico 58 – Primer modelo.
83
4º Paso: Análisis de cardinalidades mínimas.
• Una persona tiene obligatoriamente como mínimo una persona que es cabeza de familia y una persona
que es cabeza de familia puede no tener ninguna persona a su cargo.
• Una persona habita por lo menos en una vivienda y una vivienda puede que no esté habitada.
• Una vivienda tiene por lo menos una persona que sea propietaria y una persona puede que no sea propie-
taria de ninguna vivienda.
• Una persona esta empadronada por lo menos en un municipio y en un municipio tiene que haber por lo
menos una persona empadronada.
• Una vivienda esta en un único municipio y en un municipio por lo menos hay una vivienda.

Gráfico 59 – Primer modelo con cardinalidades.
5º Paso: Análisis de redundancias.
Como existen dos ciclos en el esquema E/R hay que estudiar si existe alguna interrelación redundante, es decir, si
hay alguna interrelación cuya semántica se puede obtener a partir de otras interrelaciones.
84
Base de Datos

Gráfico 60 – Ciclos del esquema.
El primer ciclo lo forman las interrelaciones Propiedad, Esta_en y Empadronada.
La primera condición para saber si tenemos un ciclo en el que haya alguna interrelación susceptible de ser redun-
dante es que las tres interrelaciones estén semánticamente relacionadas. En este caso la interrelación Propiedad
no es semánticamente equivalente a Esta_en y Empadronada, puesto que el poseer o no una vivienda no influye
en si la persona reside en el municipio en el que se encuentra la vivienda.
El segundo ciclo lo constituyen las interrelaciones Habita, Esta_en y Empadronada.

En este caso las tres relaciones están semánticamente relacionadas (suponemos que las personas habitan en los
municipios en los que están empadronadas).
Interrelación Habita: Si intentamos eliminar la interrelación Habita debe ser posible obtener su semántica a par-
tir de las otras dos relaciones del ciclo. Así, si queremos obtener las personas que habitan en una determinada
vivienda, a partir de la relación Esta_en se obtiene el municipio en el que se encuentra la vivienda y con la inte-
rrelación Empadrona se obtienen las personas que habitan en un municipio, pero no sabemos las personas que
habitan en la vivienda sino las que habitan en todas las viviendas del municipio. Por ello, la interrelación Habita
no se puede eliminar.
Interrelación Esta_en: Si intentamos eliminar la interrelación Esta_en debe ser posible obtener su semántica
a partir de las otras dos relaciones del ciclo. Para conocer las viviendas que se encuentran en un determinado
municipio, a partir de Empadrona obtenemos todas las personas empadronadas en ese municipio y mediante la
interrelación Habita obtenemos las viviendas en las que habitan esas personas (pues una persona debe habitar
obligatoriamente una vivienda); de esta forma, sabemos las viviendas de ese municipio. En el otro sentido de la
interrelación Esta_En, para conocer en qué municipio está una determinada vivienda, a partir de Habita obtene-
mos las personas que habitan en ella; sin embargo puede ocurrir que en una determinada vivienda no habite
nadie (cardinalidad mínima 0), por lo que no podemos alcanzar la interrelación empadrona entre persona y mu-
nicipio. Así, la interrelación Está_en no es redundante.
85
Interrelación Empadrona: Si intentamos eliminar la interrelación Empadrona debe ser posible obtener su se-
mántica a partir de las otras dos relaciones del ciclo. Para conocer el municipio en que está empadronada una
persona, mediante Habita obtenemos la vivienda en la que habita esa persona y con la interrelación Está_en
obtenemos el municipio en que se encuentra la vivienda; por ello conocemos el municipio en el que está em-
padronada la persona. En el otro sentido de la interrelación Empadrona, debe ser posible conocer las personas
empadronadas en un determinado municipio; mediante la interrelación Está_en conocemos las viviendas de ese
municipio y a partir de Habita sabemos todas las personas que viven en esas viviendas, conociendo así todas las
personas empadronadas en el municipio. Consecuentemente, la interrelación Empadrona se puede eliminar del
esquema E/R sin perder semántica.
Gráfico 61
Esquema terminado.
Ejercicio 3
Una empresa de aparatos electrodomésticos desea informatizar sus datos.
Escribir el diagrama MER que responda al siguiente discurso:
Cada aparato electrónico viene determinado por un código único y una descripción. Además cada aparato co-
rresponde a un tipo de electrodomésticos (a lo sumo).
Cada tipo de electrodoméstico (televisor, mp3, lavadora, etc) tiene un nombre y sus características (un campo
de texto). Se supone que no hay dos tipos con el mismo nombre y características. Algunos tipos pueden formar
parte de otro tipo más general (mp3 de aparato de música), pero en este caso solo forman parte de un único tipo.
Los componentes son las piezas que forman el aparato. Vienen dados por un nombre (por ejemplo transforma-
dor) y unas especificaciones (un campo de texto).
También nos interesa conocer datos de los fabricantes de componentes: su numero de cuit (único) y su domicilio
social.
Cada aparato puede llevar cualquier cantidad de componentes. Interesa saber para cada aparato que componen-
tes lleva y que fabricante suministra cada componente. Un aparato puede llevar muchas unidades de un mismo
componente (interesa saber cuantas), pero en este caso todas estarán suministradas por el mismo fabricante y
con un mismo precio.
86
Base de Datos
Ejercicio 4:
Se desea diseñar una base de datos para almacenar y gestionar la información empleada por un concesionario de
automóviles, teniendo en cuenta los siguientes aspectos:
A un concesionario de coches llegan clientes para comprar automóviles.

De cada coche interesa saber la matricula, modelo, marca y color.
Un cliente puede comprar varios coches en el concesionario. Cuando un cliente compra un coche, se le hace una
cha en el concesionario con la siguiente información: DNI, nombre, apellidos, dirección y teléfono.
Los coches que el concesionario vende pueden ser nuevos o usados (de segunda mano). De los coches nuevos
interesa saber el número de unidades que hay en el concesionario. De los coches viejos interesa el número de
kilómetros que lleva recorridos.
El concesionario también dispone de un taller en el que los mecánicos reparan los coches que llevan los clientes.
Un mecánico repara varios coches a lo largo del d a, y un coche puede ser reparado por varios mecánicos.
Los mecánicos tienen un DNI, nombre, apellidos, fecha de contratación y salario. Se desea guardar también la
fecha en la que se repara cada vehiculo y el numero de horas que se ha tardado en arreglar cada automóvil.
87
Ejercicio 5:
El gerente de la fabrica de muebles Rioder, Sr. Martín Cepeda, ha decidido utilizar un sistema de Base de Datos
para representar la estructura de los muebles que distribuye. Realizar el diagrama MER correspondiente teniendo
en cuenta que:
Los muebles están representados por un nombre único.

También se quiere conocer su precio.
Todo mueble esta formado por una o más piezas. Cada pieza tiene un identificador único y puede formar parte
de varios muebles. Interesa apuntar cuantas unidades de cada pieza componen el mueble.
Todas las unidades de una pieza se encuentran en uno o más estantes del depósito. El estante viene determina-
do de forma única por dos valores: pasillo y altura. Además de en que estantes están las piezas interesa conocer
cuantas unidades de la pieza hay almacenadas en cada estante.
Resumen tema 9
1er Paso: Elaborar las listas de conceptos candidatos a ser entidades e interrelaciones e indicar también los con-
ceptos que no se sabe como catalogar.
2er Paso: Construir una matriz de entidades y entidades para representar todas las interrelaciones junto con su
tipo de correspondencia. Para ello iremos analizando los supuestos semánticas explícitamente representados en
el enunciado, así como los que están implícitos o son de sentido común.
3er Paso: Obtener una versión preliminar del esquema entidad relación. A continuación se muestra una primera
versión del esquema E/R correspondiente a los supuestos del enunciado.
4º Paso: Análisis de cardinalidades mínimas.
5º Paso: Análisis de redundancias.
88
Base de Datos
Ejercitación
Ejercicio 1
A partir del siguiente enunciado se desea realiza el modelo entidad-relación.
“Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de los clientes (nom-
bre, apellidos, dni, dirección y fecha de nacimiento). Cada producto tiene un nombre y un código, así como un
precio unitario. Un cliente puede comprar varios productos a la empresa, y un mismo producto puede ser com-
prado por varios clientes. Los productos son suministrados por diferentes proveedores. Se debe tener en cuenta
que un producto sólo puede ser suministrado por un proveedor, y que un proveedor puede suministrar diferen-
tes productos. De cada proveedor se desea conocer el cuit, nombre y dirección”.
Ejercicio 2
A partir del siguiente enunciado se desea realizar el modelo entidad-relación.
“Se desea informatizar la gestión de una empresa de transportes que reparte paquetes por toda España. Los
encargados de llevar los paquetes son los camioneros, de los que se quiere guardar el dni, nombre, teléfono, di-
rección, salario y población en la que vive. De los paquetes transportados interesa conocer el código de paquete,
descripción, destinatario y dirección del destinatario. Un camionero distribuye muchos paquetes, y un paquete
sólo puede ser distribuido por un camionero. De las provincias a las que llegan los paquetes interesa guardar el
código de provincia y el nombre. Un paquete sólo puede llegar a una provincia. Sin embargo, a una provincia
pueden llegar varios paquetes. De los camiones que llevan los camioneros, interesa conocer la matrícula, modelo,
tipo y potencia. Un camionero puede conducir diferentes camiones en fechas diferentes, y un camión puede ser
conducido por varios camioneros”.
Ejercicio 3
A partir del siguiente enunciado diseñar el modelo entidad-relación.
“Se desea diseñar la base de datos de un Instituto. En la base de datos se desea guardar los datos de los profeso-
res del Instituto (DNI, nombre, dirección y teléfono). Los profesores imparten módulos, y cada módulo tiene un
código y un nombre. Cada alumno está matriculado en uno o varios módulos. De cada alumno se desea guardar
el nº de expediente, nombre, apellidos y fecha de nacimiento. Los profesores pueden impartir varios módulos,
pero un módulo sólo puede ser impartido por un profesor. Cada curso tiene un grupo de alumnos, uno de los
cuales es el delegado del grupo”.
Ejercicio 4
A partir del siguiente supuesto diseñar el modelo entidad-relación.
“Se desea diseñar una base de datos para almacenar y gestionar la información empleada por una empresa de-
dicada a la venta de automóviles, teniendo en cuenta los siguientes aspectos: La empresa dispone de una serie
de coches para su venta. Se necesita conocer la matrícula, marca y modelo, el color y el precio de venta de cada
coche. Los datos que interesa conocer de cada cliente son el dni, nombre, dirección, ciudad y número de teléfo-
no: además, los clientes se diferencian por un código interno de la empresa que se incrementa automáticamente
cuando un cliente se da de alta en ella. Un cliente puede comprar tantos coches como desee a la empresa. Un
coche determinado solo puede ser comprado por un único cliente. El concesionario también se encarga de llevar
a cabo las revisiones que se realizan a cada coche. Cada revisión tiene asociado un código que se incrementa au-
tomáticamente por cada revisión que se haga. De cada revisión se desea saber si se ha hecho cambio de filtro, si
se ha hecho cambio de aceite, si se ha hecho cambio de frenos u otros. Los coches pueden pasar varias revisiones
en el concesionario”.
89
Ejercicio 5
“La clínica “SAN PATRÁS” necesita llevar un control informatizado de su gestión de pacientes y médicos. De cada
paciente se desea guardar el código, nombre, apellidos, dirección, provincia, código postal, teléfono y fecha de
nacimiento. De cada médico se desea guardar el código, nombre, apellidos, teléfono y especialidad. Se desea lle-
var el control de cada uno de los ingresos que el paciente hace en el hospital. Cada ingreso que realiza el paciente
queda registrado en la base de datos. De cada ingreso se guarda el código de ingreso (que se incrementará auto-
máticamente cada vez que el paciente realice un ingreso), el número de habitación y cama en la que el paciente
realiza el ingreso y la fecha de ingreso. Un médico puede atender varios ingresos, pero el ingreso de un paciente
solo puede ser atendido por un único médico. Un paciente puede realizar varios ingresos en el hospital”.
Ejercicio 6
Se desea informatizar la gestión de una tienda informática.
La tienda dispone de una serie de productos que se pueden vender a los clientes.”De cada producto informático
se desea guardar el código, descripción, precio y número de existencias. De cada cliente se desea guardar el có-
digo, nombre, apellidos, dirección y número de teléfono. Un cliente puede comprar varios productos en la tienda
y un mismo producto puede ser comprado por varios clientes. Cada vez que se compre un artículo quedará
registrada la compra en la base de datos junto con la fecha en la que se ha comprado el artículo. La tienda tiene
contactos con varios proveedores que son los que suministran los productos. Un mismo producto puede ser su-
ministrado por varios proveedores. De cada proveedor se desea guardar el código, nombre, apellidos, dirección,
provincia y número de teléfono”.
Investigación
res Cuadra, Ana Iglesias, Carlos Nieto. Ra-ma.
2. Lea Concepción y diseño de base datos del Modelo E/R al Modelo Relacional - Adoración de Miguel, Mario
Piattini. Ra-ma. Capitulo15 El modelo Relacional, Capitulo 16 Dinámica del modelo relacional.
90
Base de Datos
Tema Nº 10
Modelo relacional
Edgar Frank Codd definió las bases del modelo relacional a finales de los 60. En 1970 publica el documento “A Re-
lational Model of data for Large Shared Data Banks” (Un modelo relacional de datos para grandes bancos de datos
compartidos). Actualmente se considera que ese es uno de los documentos más influyentes de toda la historia
de la informática. Lo es porque en él se definieron las bases del llamado Modelo Relacional de Bases de Datos.
Anteriormente el único modelo teórico estandarizado era el Codasyl que se utilizó masivamente en los años 70
como paradigma del modelo en red de bases de datos.
Codd se apoya en los trabajos de los matemáticos Cantor y Childs (cuya teoría de conjuntos es la verdadera base
del modelo relacional). Según Codd los datos se agrupan en relaciones (actualmente llamadas tablas) que es un
concepto que se refiere a la estructura que aglutina datos referidos a una misma entidad de forma independiente
respecto a su almacenamiento físico.
Lo que Codd intentaba fundamentalmente es evitar que las usuarias y usuarios de la base de datos tuvieran que
verse obligadas a aprender los entresijos internos del sistema. Pretendía que los usuarios/as trabajaran de forma
sencilla e independiente del funcionamiento físico de la base de datos en sí. Fue un enfoque revolucionario.
Aunque trabajaba para IBM, esta empresa no recibió de buen grado sus teorías (de hecho continuó trabajando en
su modelo en red IMS). De hecho fueron otras empresas (en especial Oracle) las que implementaron sus teorías.
Pocos años después el modelo se empezó a utilizar cada vez más, hasta finalmente ser el modelo de bases de
datos más popular. Hoy en día casi todas las bases de datos siguen este modelo.
Objetivos
• Independencia física. La forma de almacenar los datos, no debe influir en su manipulación lógica. Si la for-
ma de almacenar los datos cambia, los usuarios no tienen siquiera porque percibirlo y seguirán trabajando
de la misma forma con la base de datos. Esto permite que los usuarios y usuarias se concentren en qué
quieren consultar en la base de datos y no en cómo está realizada la misma.
• Independencia lógica. Las aplicaciones que utilizan la base de datos no deben ser modificadas porque se
modifiquen elementos de la base de datos. Es decir, añadir, borrar y suprimir datos, no influye en las vistas
de los usuarios. De una manera más precisa, gracias a esta independencia el esquema externo de la base
de datos es realmente independiente del modelo lógico.
• Flexibilidad. La base de datos ofrece fácilmente distintas vistas en función de los usuarios y aplicaciones.
• Uniformidad. Las estructuras lógicas siempre tienen una única forma conceptual (las tablas).
• Sencillez. Facilidad de manejo (algo cuestionable, pero ciertamente verdadero si comparamos con los sis-
temas gestores de bases de datos anteriores a este modelo).
Relación o tabla
Según el modelo relacional (desde que Codd lo enunció) el elemento fundamental es lo que se conoce como
relación, aunque más habitualmente se le llama tabla (o también array o matriz). Codd definió las relaciones
utilizando un lenguaje matemático, pero se pueden asociar a la idea de tabla (de filas y columnas) ya que es más
fácil de entender.
No hay que confundir la idea de relación según el modelo de Codd, con lo que significa una relación en el
modelo Entidad/Relación de Chen. No tienen nada que ver.
91
Las relaciones constan de:

Atributos. Referido a cada propiedad de los datos que se almacenan en la relación (nombre, dni,...).
Tuplas. Referido a cada elemento de la relación. Por ejemplo si una relación almacena personas, una tupla repre-
sentaría a una persona en concreto.
Puesto que una relación se representa como una tabla; podemos entender que las columnas de la tabla son los
atributos; y las filas, las tuplas.

Gráfico 62 - relación según el modelo de Codd.
Tupla
Cada una de las filas de la relación. Se corresponde con la idea clásica de registro. Representa por tanto cada ele-
mento individual de esa relación. Tiene que cumplir que:
• Cada tupla se debe corresponder con un elemento del mundo real.

• No puede haber dos tuplas iguales (con todos los valores iguales).
Dominio
Un dominio contiene todos los posibles valores que puede tomar un determinado atributo. Dos atributos distin-
tos pueden tener el mismo dominio.
Un dominio en realidad es un conjunto finito de valores del mismo tipo. A los dominios se les asigna un nombre
y así podemos referirnos a ese nombre en más de un atributo.
La forma de indicar el contenido de un dominio se puede hacer utilizando dos posibles técnicas:
• Intensión. Se define el nomino indicando la definición exacta de sus posibles valores. Por intensión se pue-
de definir el dominio de edades de los trabajadores como: números enteros entre el 16 y el 65 (un trabaja-
dor sólo podría tener una edad entre 16 y 65 años).
• Extensión. Se indican algunos valores y se sobreentiende el resto gracias a que se autodefinen con los
anteriores. Por ejemplo el dominio provincia se podría definir por extensión así: Jujuy, Salta, Catamarca,
Formosa, etc ….
Además pueden ser:

• Generales. Los valores están comprendidos entre un máximo y un mínimo.
• Restringidos. Sólo pueden tomar un conjunto de valores.
92
Base de Datos
Grado
Indica el tamaño de una relación en base al número de columnas (atributos) de la misma. Lógicamente cuanto
mayor es el grado de una relación, mayor es su complejidad al manejarla.
Cardinalidad
Número de tuplas de una relación, o número de filas de una tabla.
Sinónimo
Los términos vistos anteriormente tienen distintos sinónimos según la nomenclatura utilizada. A ese respecto se
utilizan tres nomenclaturas:
Gráfico 63 – Comparación de nomenclaturas.
Definición formal de relación

Una relación está formada por estos elementos:
• Nombre. Identifica la relación.
• Cabecera de relación. Conjunto de todos los pares atributo-domino de la relación:
donde n es el grado.

• Cuerpo de la relación. Representa el conjunto de m tuplas {t1, t2,... tn} que forman la relación.
Cada tupla es un conjunto de n pares atributo-valor, donde Vij es el valor j

del dominio Di asociado al atributo Ai.

• Esquema de la relación. Se forma con el nombre R y la cabecera. Es decir:

• Estado de la relación. Lo forman el esquema y el cuerpo.

Gráfico 64 – Ejemplo de Relación.
93
Propiedades de las tablas o relaciones

1. Cada tabla tiene un nombre distinto.
2. Cada atributo de la tabla toma un solo valor en cada tupla.
3. Cada atributo tiene un nombre distinto en cada tabla (aunque puede coincidir en tablas distintas).
4. Cada tupla es única (no hay tuplas duplicadas).
5. El orden de los atributos no importa.
6. El orden de las tuplas no importa.
Tipos de tablas
Persistentes. Sólo pueden ser borradas por los usuarios:
• Bases. Independientes, se crean indicando su estructura y sus ejemplares. Contienen tanto datos como
metadatos.
• Vistas. Son tablas que sólo almacenan una definición de consulta, resultado de la cual se produce una tabla
cuyos datos proceden de las bases o de otras vistas e instantáneas. Si los datos de las tablas base cambian,
los de la vista que utiliza esos datos también cambia.
• Instantáneas. Son vistas (creadas de la misma forma) que sí que almacenan los datos que muestra, además
de la consulta que dio lugar a esa vista. Sólo modifican su resultado (actualizan los datos) siendo refrescadas
por el sistema cada cierto tiempo (con lo que tienen el riesgo de que muestren algunos datos obsoletos.
• Temporales. Son tablas que se eliminan automáticamente por el sistema. Pueden ser de cualquiera de los
tipos anteriores. Las utiliza el SGBD como almacén intermedio de datos (resultados de consultas, por ejemplo).
Claves
Clave Candidata: Conjunto de atributos que identifican unívocamente cada tupla de la relación. Es decir colum-
nas cuyos valores no se repiten en ninguna otra tupla de esa tabla. Toda tabla en el modelo relacional debe tener
al menos una clave candidata (puede incluso haber más).
Clave Primaria: Clave candidata que se escoge como identificador de las tuplas. Se elige como primaria la candi-
data que identifique mejor a cada tupla en el contexto de la base de datos.
Por ejemplo un campo con el DNI sería clave candidata de una tabla de clientes, si esa tabla tiene un campo de
código de cliente, éste sería mejor candidato (y por lo tanto clave principal) porque es mejor identificador para
ese contexto.
Clave Alternativa: Cualquier clave candidata que no sea primaria.
Clave externa, ajena o secundaria: Son los datos de atributos de una tabla cuyos valores están relacionados con
atributos de otra tabla. Por ejemplo en la tabla equipos tenemos estos datos:
Gráfico 65
Tabla equipos.
94
Base de Datos
En la tabla anterior la clave principal es el atributo nº equipo. En otra tabla tenemos:
Gráfico 66
Tabla jugadores.
El atributo Nº Equipo sirve para relacionar el Jugador con el equipo al que pertenece. Ese campo en la tabla de
jugadores es una clave secundaria.
Nulos
En los lenguajes de programación se utiliza el valor nulo para reflejar que un identificador (una variable, un obje-
to,..) no tiene ningún contenido. Por ejemplo cuando un puntero en lenguaje C señala a null se dice que no está
señalando a nadie. Al programar en esos lenguajes se trata de un valor que no permite utilizarse en operaciones
aritméticas o lógicas.
Las bases de datos relacionales permiten más posibilidades para el valor nulo (null), aunque su significado no
cambia: valor vacío. No obstante en las bases de datos se utiliza para diversos fines.
En claves secundarias indican que el registro actual no está relacionado con ninguno. En otros atributos indica
que la tupla en cuestión carece de dicho atributo: por ejemplo en una tabla de personas un valor nulo en el atri-
buto teléfono indicaría que dicha persona no tiene teléfono.
Es importante indicar que el texto vacío ‘ ’, no significa lo mismo en un texto que el nulo; como tampoco el valor
cero significa nulo.
Puesto que ese valor se utiliza continuamente, resulta imprescindible saber cómo actúa cuando se emplean ope-
raciones lógicas sobre ese valor. Eso significa definir un tercer valor en la lógica booleana, además de los clásicos
verdadero y falso. Un valor nulo no es ni verdadero ni falso (se suele interpretar como un quizás, o usando la arit-
mética clásica en valores lógicos, el 1 es verdadero, el 0 falso y el 0,5 nulo).
El uso de operadores lógicos con el nulo da lugar a que:

• Verdadero Y (AND) nulo da como resultado, nulo (siguiendo la aritmética planteada antes: 1·0,5=0,5)
• Falso Y (AND) nulo da como resultado, falso (0·0,5=0)
• Verdadero O (OR) nulo da como resultado, verdadero (1+0,5>1)
• falso O nulo da como resultado nulo (0+0,5=0,5)
• La negación de nulo, da como resultado nulo
Se utiliza un operador en todas las bases relacionales llamado es nulo (is null) que devuelve verdadero si el valor
con el que se compara es nulo.
95
Resumen tema 10
Objetivos del modelo relacional
1. Independencia física. La forma de almacenar los datos, no debe influir en su manipulación lógica.
2. Independencia lógica. Las aplicaciones que utilizan la base de datos no deben ser modificadas porque se
modifiquen elementos de la base de datos.
3. Flexibilidad. La base de datos ofrece fácilmente distintas vistas en función de los usuarios y aplicaciones.
4. Uniformidad. Las estructuras lógicas siempre tienen una única forma conceptual (las tablas).
5. Sencillez. Facilidad de manejo (algo cuestionable, pero ciertamente verdadero si comparamos con los sis-
temas gestores de bases de datos anteriores a este modelo).
Relación o tabla
Según el modelo relacional el elemento fundamental es lo que se conoce como relación, aunque más habitual-
mente se le llama tabla Codd definió las relaciones utilizando un lenguaje matemático, pero se pueden asociar
a la idea de tabla (de filas y columnas) ya que es más fácil de entender.
1. Atributos. Referido a cada propiedad de los datos que se almacenan en la relación.

2. Tuplas. Referido a cada elemento de la relación.
Dominio
Un dominio contiene todos los posibles valores que puede tomar un determinado atributo. Dos atributos distin-
tos pueden tener el mismo dominio. La forma de indicar el contenido de un dominio se puede hacer utilizando
dos posibles técnicas:
1. Intensión. Se define el nomino indicando la definición exacta de sus posibles valores.

2. Extensión. Se indican algunos valores y se sobreentiende el resto gracias a que se autodefinen
con los anteriores.
3. Generales. Los valores están comprendidos entre un máximo y un mínimo.
4. Restringidos. Sólo pueden tomar un conjunto de valores.
Grado
Indica el tamaño de una relación en base al número de columnas (atributos) de la misma
Cardinalidad
Número de tuplas de una relación, o número de filas de una tabla.
Definición formal de relación

Una relación está formada por estos elementos:
1. Nombre. Identifica la relación.

2. Cabecera de relación. Conjunto de todos los pares atributo-domino de la relación.
3. Cuerpo de la relación. Representa el conjunto de n tuplas que forman la relación.
4. Esquema de la relación. Se forma con el nombre R y la cabecera.
5. Estado de la relación. Lo forman el esquema y el cuerpo.
96
Base de Datos
Propiedades de las relaciones o tablas

1. Cada tabla tiene un nombre distinto.
2. Cada atributo de la tabla toma un solo valor en cada tupla.
3. Cada atributo tiene un nombre distinto en cada tabla (aunque puede coincidir en tablas distintas).
4. Cada tupla es única (no hay tuplas duplicadas).
5. El orden de los atributos no importa.
6. El orden de las tuplas no importa.
Tipos de tablas
1. Persistentes. Sólo pueden ser borradas por los usuarios:
a) Bases. Independientes, se crean indicando su estructura y sus ejemplares. Contienen tanto datos como meta-
datos.
b) Vistas. Son tablas que sólo almacenan una definición de consulta, resultado de la cual se produce una tabla
cuyos datos proceden de las bases o de otras vistas e instantáneas.
c) Instantáneas. Son vistas (creadas de la misma forma) que sí que almacenan los datos que muestra, además de
la consulta que dio lugar a esa vista.
2.Temporales. Son tablas que se eliminan automáticamente por el sistema.
Claves
Claves candidatas: Conjunto de atributos que identifican unívocamente cada tupla de la relación.
Clave primaria: de la clave candidata que se escoge como identificador de las tuplas. Se elige como primaria la
candidata que identifique mejor a cada tupla en el contexto de la base de datos.
Clave alternativa: Cualquier clave candidata que no sea primaria.
Clave secundaria: Son los datos de atributos de una tabla cuyos valores están relacionados con atributos de otra
tabla.
Autoevaluación
1. ¿Cuál es el elemento más importante en el modelo relacional?
2. ¿Cuáles son los elementos de una relación?
3. Es correcta la afirmación de que la idea de relación según el modelo de Codd, es lo mismo que la idea de rela-
ción en el modelo Entidad/Relación de Chen. Justifique.
4. Si hablo de los objetivos del modelo relacional y me refiero digo que la forma de almacenar los datos, no debe
influir en su manipulación lógica. ¿a que me estoy refiriendo?
5. Si defino el rango de edades de los trabajadores como: números enteros entre el 18 y el 65, para mi tabla em-
pleados. ¿Qué estoy definiendo?
6. Si para mi tabla o relación de Vehículo tengo los siguientes campos: marca, modelo, patente, numero de motor
y numero de chasis.
a. ¿Qué tipo de claves utilizaría para reconocerlo unívocamente?
b. Identifique a las demás.
7. ¿Cuál es la diferencia entre tablas permanentes y temporales?
Investigación
1. Indague sobre la historia del modelo relacional.
2. Lea de Sistemas de base de datos – C.J. Date – Addison-Wesley Iberoamericana. Capitulo 11 Estructura del mo-
delo relacional.
97
Tema Nº 11
Restricciones
Se trata condiciones de obligado cumplimiento por las tuplas de la base de datos. Las hay de varios tipos.
Inherentes
Son aquellas que no son determinadas por los usuarios, sino que son definidas por el hecho de que la base de
datos sea relacional. Las más importantes son:
• No puede haber dos tuplas iguales.

• El orden de las tuplas no es significativo.
• El orden de los atributos no es significativo.
• Cada atributo sólo puede tomar un valor en el dominio en el que está inscrito.
Semánticas
El modelo relacional permite a los usuarios incorporar restricciones personales a los datos. Se comentan las dife-
rentes reglas semánticas a continuación:
Clave principal (primary key)

También llamada clave primaria. Marca uno o más atributos como identificadores de la tabla. De esa forma
en esos atributos las filas de la tabla no podrán repetir valores ni tampoco dejarlos vacíos.
Inucidad (unique).
Impide que los valores de los atributos marcados de esa forma, puedan repetirse. Esta restricción debe indi-
carse en todas las claves alternativas.
Al marcar una clave primaria se añade automáticamente sobre los atributos que forman la clave un criterio
de unicidad.
Obligatoriedad (not null).

Prohíbe que el atributo marcado de esta forma quede vacío (es decir impide que pueda contener el valor
nulo, null).
Integridad referencial.
Sirve para indicar una clave externa (también llamada secundaria y foránea) sobre uno o más atributos. Los
atributos marcados de esta forma sólo podrán contener valores que estén relacionados con la clave princi-
pal de la tabla que relacionan (llamada tabla principal). Dichos atributos sí podrán contener valores nulos.
Es decir si hay una tabla de alquileres en la que cada fila es un alquiler, existirá un atributo cod_cliente que
indicará el código del cliente y que estará relacionado con una tabla de clientes, en la que dicho atributo
es la clave principal. De hecho no se podrá incluir un código que no esté en la tabla clientes; eso es lo que
prohíbe la integridad referencial.
Gráfico 67
Ejemplo clave
secundaria.

98
Base de Datos
Eso causa problemas en las operaciones de borrado y modificación de registros; ya que si se ejecutan esas opera-
ciones sobre la tabla principal (si se modifica o borra un cliente) quedarán filas en la tabla secundaria con la clave
externa haciendo referencia a un valor que ya no existe en la tabla principal.
Para solventar esta situación se puede hacer uso de estas opciones:
• Prohibir la operación (no action).

• Transmitir la operación en cascada (cascade). Es decir si se modifica o borra un cliente; también se modifi-
carán o barrarán los alquileres relacionados con él.
• Colocar nulos (set null) Las referencias al cliente en la tabla de alquileres se colocan como nulos (es decir,
alquileres sin cliente).
• Usar el valor por defecto (default). Se colocan un valor por defecto en las claves externas relacionadas. Este
valor se indica al crear la tabla (opción default).
Regla de validación (check)

Condición lógica que debe de cumplir un dato concreto para darlo por válido. Por ejemplo restringir el campo
sueldo para que siempre sea mayor de 1000, sería una regla de validación. También por ejemplo que la fecha de
inicio sea mayor que la fecha final.
Disparadores o triggers
Se trata de pequeños programas grabados en la base de datos que se ejecutan automáticamente cuando se cum-
ple una determinada condición. Sirven para realizar una serie de acciones cuando ocurre un determinado evento
(cuando se añade una tupla, cuando se borra un dato, cuando un usuario abre una conexión…)
Los triggers permiten realizar restricciones muy potentes; pero son las más difíciles de crear.
Las doce reglas de Codd

Preocupado por los productos que decían ser sistemas gestores de bases de datos relacionales (RDBMS) sin serlo,
Codd publica las 12 reglas que debe cumplir todo DBMS para ser considerado relacional. Estas reglas en la prác-
tica las cumplen pocos sistemas relacionales. Las reglas son:
1. Información. Toda la información de la base de datos (metadatos) debe estar representada explícitamente
en el esquema lógico. Es decir, todos los datos están en las tablas.
2. Acceso garantizado. Todo dato es accesible sabiendo el valor de su clave y el nombre de la columna o atri-
buto que contiene el dato.
3. Tratamiento sistemático de los valores nulos. El DBMS debe permitir el tratamiento adecuado de estos va-
lores. De ese modo el valor nulo se utiliza para representar la ausencia de información de un determinado
registro en un atributo concreto.
4. Catálogo en línea basado en el modelo relacional. Los metadatos deben de ser accesibles usando un es-
quema relacional. Es decir la forma de acceder a los metadatos es la misma que la de acceder a los datos.
5. Sublenguaje de datos completo. Al menos debe de existir un lenguaje que permita el manejo completo de
la base de datos. Este lenguaje, por lo tanto, debe permitir realizar cualquier operación sobre la misma.
6. Actualización de vistas. El SGBD debe encargarse de que las vistas muestren la última información. No son
válidas vistas que muestren datos que no están al día.
99
7. Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier operación de modificación debe ac-
tuar sobre conjuntos de filas o registros, nunca deben actuar registro a registro.
8. Independencia física. Los datos deben de ser accesibles desde la lógica de la base de datos aún cuando se
modifique el almacenamiento. La forma de acceder a los datos no varía porque el esquema físico de la base
de datos, cambie.
9. Independencia lógica. Los programas no deben verse afectados por cambios en las tablas. Que las tablas
cambien no implica que cambien los programas.
10. Independencia de integridad. Las reglas de integridad deben almacenarse en la base de datos (en el dic-
cionario de datos), no en los programas de aplicación.
11. Independencia de la distribución. El sublenguaje de datos debe permitir que sus instrucciones funciones
igualmente en una base de datos distribuida que en una que no lo es.
12. No subversión. Si el SGBD posee un lenguaje procedimental que permita crear bucles de recorrido fila a
fila, éste no puede utilizarse para incumplir o evitar las reglas relacionales anteriores. Especialmente la re-
gla 7 no puede ser incumplida por ningún lenguaje del SGBD.
Pasaje de modelo entidad/relación a modelo relacional

Transformación de entidades fuertes
En principio las entidades fuertes del modelo Entidad Relación son transformadas al modelo relacional siguiendo
estas instrucciones:
• Entidades. Las entidades pasan a ser tablas

• Atributos. Los atributos pasan a ser columnas o atributos de la tabla.
• Identificadores principales. Pasan a ser claves primarias
• Identificadores candidatos. Pasan a ser claves candidatas.
Esto hace que la transformación se produzca según este ejemplo:
Gráfico 68 – Transformación de ME/R a MR.
100
Base de Datos
Transformación de relaciones
La idea inicial es transformar cada relación del modelo conceptual en una tabla en el modelo relacional. Pero hay
casos en los que esta regla tiene matices y no se cumple.
Relaciones muchos a muchos

En las relaciones muchos a muchos (n a n en la cardinalidad mayor, la cardinalidad menor no cuenta para esta
situación), la relación se transforma en una tabla cuyos atributos son: los atributos de la relación y las claves de las
entidades relacionadas (que pasarán a ser claves externas). La clave de la tabla la forman todas las claves externas.

Gráfico 69 – Transformación de una relación N:M.
Relaciones de grado n
Las relaciones ternarias, cuaternarias y n-arias que unen más de dos relaciones se transforman en una tabla que
contiene los atributos de la relación más los identificadores de las entidades relacionadas. La clave la forman
todas las claves externas:

Gráfico 70 – Transformación relación de grado n.
101
Relaciones 1 a muchos
Las relaciones binarios de tipo uno a muchos o varios no requieren ser transformadas en una tabla en el modelo
relacional. En su lugar la tabla del lado varios (tabla relacionada) incluye como clave externa1 el identificador de
la entidad del lado uno (tabla principal).
Gráfico 71 – Transformación relación 1:N.
Así en el Gráfico, el Identificador2 en la tabla Entidad1 pasa a ser una clave secundaria. En el caso de que el nú-
mero mínimo de la relación sea de cero (puede haber ejemplares de la entidad uno sin relacionar), se deberá
permitir valores nulos en la clave secundaria (en el ejemplo sería el identificador2 en la Entidad1). En otro caso no
se podrán permitir (ya que siempre habrá un valor relacionado).
Relación 1 a 1
En el caso de las relaciones entre dos entidades con todas las cardinalidades a 1; hay dos posibilidades:
• Colocar la clave de una de las entidades como clave externa de la otra tabla (da igual cuál), teniendo en
cuenta que dicha clave será clave alternativa además de ser clave secundaria.
• Generar una única tabla con todos los atributos de ambas entidades colocando como clave principal cual-
quiera de las claves de las dos entidades. La otra clave será marcada como clave alternativa. El nombre de la
tabla sería el de la entidad más importante desde el punto de vista conceptual.

Gráfico 72 – Transformación relación 1:1.
102
Base de Datos
Relación de 0 a 1
Se trata de relaciones entre dos entidades con cardinalidad máxima de 1 en ambas direcciones, pero en una de
ellas la cardinalidad mínima es 0. En este caso la solución difiere respecto a la anterior solución. No conviene ge-
nerar una única tabla ya que habría numerosos valores nulos en la tabla (debido a que hay ejemplares que no se
relacionan en las dos tablas).
La solución sería generar dos tablas, una para cada entidad. En la tabla con cardinalidad 0, se coloca como clave
secundaria, la clave principal de la otra (dicha clave sería clave alternativa de esa tabla):

Gráfico 73 – Transformación relación 0:1.
En el caso de que en ambos extremos nos encontremos con relaciones 0 a 1, entonces la solución es la misma,
pero la clave que se copia en la tabla para ser clave secundaria, debe de ser tomada de la entidad que se relacione
más con la otra (la que esté más cerca de tener la cardinalidad 1 a 1 en el otro extremo). Dicha clave secundaria,
en este caso, no será clave alternativa (pero sí tendría restricción de unicidad).
Relaciones recursivas
Las relaciones recursivas se tratan de la misma forma que las otras, sólo que un mismo atributo puede figurar dos ve-
ces en una tabla como resultado de la transformación (por eso es interesante indicar el rol en el nombre del atributo.

Gráfico 74 – Transformación relaciones recursivas en MR.
Entidades débiles
Toda entidad débil incorpora una relación implícita con una entidad fuerte. Esta relación no necesita incorporarse
como tabla en el modelo relacional (al tratarse de una relación n a 1), bastará con añadir como atributo y clave
foránea en la entidad débil, el identificador de la entidad fuerte.
103
En ocasiones el identificador de la entidad débil tiene como parte de su identificador al identificador de la enti-
dad fuerte (por ejemplo si para identificar líneas de factura utilizamos el número de línea y el número de factura,
clave de la entidad factura). En esos casos no hace falta añadir de nuevo como clave externa el identificador de la
entidad fuerte (imagen de la derecha)

Gráfico 75 – Transformación relaciones entidades débiles.
Relaciones ISA
En el caso de las relaciones ISA, se siguen estas normas:
1. Tanto las superentidades como las subentidades generarán tablas en el modelo relacional (en el caso de
que la ISA sea de tipo total, se podría incluso no hacer la superentidad y pasar todos sus atributos a las
subentidades, pero no es recomendable porque puede complicar enormemente el esquema interno).
2. Los atributos se colocan en la tabla a la que se refiere a la entidad correspondiente
3. En el caso de que las subentidades no hereden el identificador con la superentidad, se colocará en las su-
bentidades el identificador de la superentidad como clave secundaria, además será clave alternativa.
4. Si la ISA es exclusiva o no, no cambia el esquema relacional, pero sí habrá que tenerlo en cuenta para las
restricciones futuras en el esquema interno (casi siempre se realizan mediante triggers), ya que en las ex-
clusivas no se puede repetir la clave de la superentidad en las subentidades.
Gráfico 76
Transformación
relaciones ISA.

104
Base de Datos
Resumen tema 11
Restricciones
Se trata condiciones de obligado cumplimiento por las tuplas de la base de datos. Las hay de varios tipos.
1. Inherentes:
a. Son aquellas que no son determinadas por los usuarios
2.Semánticas:
El modelo relacional permite a los usuarios incorporar restricciones personales a los datos. Se comentan las dife-
rentes reglas semánticas a continuación:
a. Clave principal (primary key)

b. Inucidad (unique).
c. Obligatoriedad (not null).
d. Integridad referencial.
e. Regla de validación (check).
f. Disparadores o triggers.
Reglas de Codd
Preocupado por los productos que decían ser sistemas gestores de bases de datos relacionales (RDBMS) sin serlo,
Codd publica las 12 reglas que debe cumplir todo DBMS para ser considerado relacional.
1. Información.
2. Acceso garantizado.
3. Tratamiento sistemático de los valores nulos.
4. Catálogo en línea basado en el modelo relacional.
5. Sublenguaje de datos completo.
6. Actualización de vistas.
7. Inserciones, modificaciones y eliminaciones de dato nivel.
8. Independencia física.
9. Independencia lógica.
10. Independencia de integridad.
11. Independencia de la distribución.
12. No subversión.
Transformación de entidades
1. Entidades. Las entidades pasan a ser tablas

2. Atributos. Los atributos pasan a ser columnas o atributos de la tabla.
3. Identificadores principales. Pasan a ser claves primarias
4. Identificadores candidatos. Pasan a ser claves candidatas.
105
Transformación de entidades
Relaciones de grado n
Las relaciones ternarias, cuaternarias y n-arias que unen más de dos relaciones se transforman en una tabla
que contiene los atributos de la relación más los identificadores de las entidades relacionadas.
Relaciones 1 a muchos
Las relaciones binarios de tipo uno a muchos la tabla del lado varios (tabla relacionada) incluye como clave
externa1 el identificador de la entidad del lado uno (tabla principal).
Relación 1 a 1
En el caso de las relaciones entre dos entidades con todas las cardinalidades a 1; hay dos posibilidades:
Colocar la clave de una de las entidades como clave externa de la otra tabla (da igual cuál), teniendo en
cuenta que dicha clave será clave alternativa además de ser clave secundaria.
Generar una única tabla con todos los atributos de ambas entidades colocando como clave principal
cualquiera de las claves de las dos entidades. La otra clave será marcada como clave alternativa.
Relación de 0 a 1
La solución sería generar dos tablas, una para cada entidad. En la tabla con cardinalidad 0, se coloca como
clave secundaria, la clave principal de la otra (dicha clave sería clave alternativa de esa tabla).
Relaciones recursivas.
Las relaciones recursivas se tratan de la misma forma que las otras, sólo que un mismo atributo puede figu-
rar dos veces en una tabla como resultado de la transformación (por eso es interesante indicar el rol en el
nombre del atributo.
Entidades débiles
Toda entidad débil incorpora una relación implícita con una entidad fuerte. Esta relación no necesita in-
corporarse como tabla en el modelo relacional (al tratarse de una relación n a 1), bastará con añadir como
atributo y clave foránea en la entidad débil, el identificador de la entidad fuerte.
Relaciones ISA
En el caso de las relaciones ISA, se siguen estas normas:
1. Tanto las superentidades como las subentidades generarán tablas en el modelo relacional (en el caso de
que la ISA sea de tipo total, se podría incluso no hacer la superentidad y pasar todos sus atributos a las
subentidades, pero no es recomendable porque puede complicar enormemente el esquema interno).
2. Los atributos se colocan en la tabla a la que se refiere a la entidad correspondiente
3. En el caso de que las subentidades no hereden el identificador con la superentidad, se colocará en las su-
bentidades el identificador de la superentidad como clave secundaria, además será clave alternativa.
4. Si la ISA es exclusiva o no, no cambia el esquema relacional, pero sí habrá que tenerlo en cuenta para las
restricciones futuras en el esquema interno (casi siempre se realizan mediante triggers), ya que en las ex-
clusivas no se puede repetir la clave de la superentidad en las subentidades.
106
Base de Datos
Autoevaluación
1. Si tengo dos tablas la primera: Empleado con los siguientes campos: numero de legajo, nombre, apellido, anti-
güedad, dni. La segunda tabla salario_empleado tiene los siguientes campos: numero legajo, categoría. ¿Qué
significancia tiene número de legajo en ambas tablas?
2. Estoy diseñando una base para una empresa de transportes y me piden ciertas restricciones (a,b,c) para la tabla
choferes los campos son los siguiente licencia de conducir, nombre, apellido, dirección, estado civil, teléfono y
DNI. ¿Qué tipo de restricciones son las siguientes?
a. Que no se repita el número de licencia de conducir ya que es la clave primaria.

b. El número de documento no puede faltar.
c. Estado civil no puede pasar de soltero a viudo.
Ejercitación
Pasar de ME/R a MR.
Ejercicio 1
Nombre Precio
Dni Apellido Cod_producto Nombre Cuit Nombre
N:M
1:M
(0,n) (0,n) (1,n) (m,n)

Cliente compra Producto Suministra Proveedor
Fecha_nac Telefono Direccion
107
Ejercicio 2
Nombre Modelo
Dni Telefono Matricula Potencia
Direcciom
N:M Tipo
(0,n) (0,n)
Salario Camionero Conduce Camion
Poblacion (0,1)
Distribuye 1:M
Cod_proveedor Nombre
(1,n)
Destinatario
1:M
(0,m) (1,1)
Cod_paquete Paquete Suministra Proveedor
Descripcion Direccion
Ejercicio 3
Nombre
Nombre
Dni Telefono
Direccion Fech_nac
(0,m)
(1,1)
Profesor Es delegado Alumno Expediente
1:M (1,n)
Apellido
(1:1) M:N Cursa
(1,n)
1:M
(1,n)
Imparte Modulo
Cod_modulo
108
Base de Datos
Ejercicio 4
Modelo
Nombre
Ciudad Matricula Marca
Dni
Color
1:M
Direccion (0,1) (1,n)
Cliente Compra Coche
Precio
Telefono (1,1)
1:M Pasa
Filtro (0,n)
Aceite Revision
Frenos
Cod_revision
Ejercicio 5
Nombre
Cod_medico
Medico
Apellido
(1,1)
Atiende 1:M
Cod_paciente Nombre
(0,m)
1:M Apellido
Ingreso (1,m) Realiza (1,1) Paciente
Cod_ingreso
Habitacion Fecha
109
Ejercicio 6
Existencia Precio Cod_cliente Nombre
Cod_producto
M:N Apellido
(0,m)
Producto Compra (0,m) Cliente
Descripcion
Direccion
(1,m) Telefono
Suministra M:N
(1,m)
Nombre
Proveedor
Cod_ingreso
Direccion
Telefono
Apellido
Investigación
1. Lea Sistemas de base de datos – C.J. Date – Addison-Wesley Iberoamericana. Capitulo 12 Reglas de identidad.
3. Visite http://www.dba-oracle.com/art_builder_ri.htm
4. Visite http://msdn.microsoft.com/en-us/library/aa902684(v=sql.80).aspx
110
Base de Datos
Tema Nº 12
Normalización
Una vez obtenido el esquema relacional resultante del esquema entidad/relación que representa la base de datos,
normalmente tendremos una buena base de datos. Pero otras veces, debido a fallos en el diseño o a problemas
indetectables, tendremos un esquema que puede producir una base de datos que incorpore estos problemas:
• Redundancia. Se llama así a los datos que se repiten continua e innecesariamente por las tablas de las bases
de datos. Cuando es excesiva es evidente que el diseño hay que revisarlo, es el primer síntoma de proble-
mas y se detecta fácilmente.
• Ambigüedades. Datos que no clarifican suficientemente el registro al que representan. Los datos de cada
registro podrían referirse a más de un registro o incluso puede ser imposible saber a qué ejemplar exacta-
mente se están refiriendo. Es un problema muy grave y difícil de detectar.
• Pérdida de restricciones de integridad. Normalmente debido a dependencias funcionales. Más adelante se

explica este problema. Se arreglan fácilmente siguiendo una serie de pasos concretos.
• Anomalías en operaciones de modificación de datos. El hecho de que al insertar un solo elemento haya que
repetir tuplas en una tabla para variar unos pocos datos. O que eliminar un elemento suponga eliminar va-
rias tuplas necesariamente (por ejemplo que eliminar un cliente suponga borrar seis o siete filas de la tabla
de clientes, sería un error muy grave y por lo tanto un diseño terrible).
El principio fundamental reside en que las tablas deben referirse a objetos o situaciones muy concretas, relacio-
nados exactamente con elementos reconocibles por el sistema de información de forma inequívoca. Cada fila de
una tabla representa inequívocamente un elemento reconocible en el sistema. Lo que ocurre es que conceptual-
mente es difícil agrupar esos elementos correctamente.
En cualquier caso la mayor parte de problemas se agravan si no se sigue un modelo conceptual y se decide crear
directamente el esquema relacional. En ese caso el diseño tiene una garantía casi asegurada de funcionar mal.
Cuando aparecen los problemas enumerados entonces se les puede resolver usando reglas de normalización.
Estas reglas suelen forzar la división de una tabla en dos o más tablas para arreglar ese problema.
Formas normales
Las formas normales se corresponde a una teoría de normalización iniciada por el propio Codd y continuada por
otros autores (entre los que destacan Boyce y Fagin). Codd definió en 1970 la primera forma normal, desde ese
momento aparecieron la segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma normal.
Una tabla puede encontrarse en primera forma normal y no en segunda forma normal, pero no al contrario. Es
decir los números altos de formas normales son más restrictivos (la quinta forma normal cumple todas las ante-
riores).
La teoría de formas normales es una teoría absolutamente matemática, pero en el presente manual se describen
de forma más intuitiva.
Hay que tener en cuenta que muchos diseñadores opinan que basta con llegar a la forma Boyce-Codd, ya que
la cuarta, y sobre todo la quinta, forma normal es polémica. Hay quien opina que hay bases de datos peores en
quinta forma normal que en tercera. En cualquier caso debería ser obligatorio para cualquier diseñador llegar
hasta la forma normal de Boyce-Codd.
111
Primera forma normal - FN1

Es una forma normal inherente al esquema relacional. Es decir toda tabla realmente relacional la cumple.
Se dice que una tabla se encuentra en primera forma normal si impide que un atributo de una tupla pueda tomar
más de un valor. La tabla:

Gráfico 77 – Tabla trabajador sin normalizar.
Visualmente es una tabla, pero no una tabla relacional (lo que en terminología de bases de datos relacionales se
llama relación). No cumple la primera forma normal.
Sería primera forma normal si los datos fueran:
Gráfico 78 – Tabla trabajador normalizada 1FN.
Esa tabla sí está en primera forma normal.
Dependencia funcional
Se dice que un conjunto de atributos (Y) depende funcionalmente de otro conjunto de atributos (X) si para cada
valor de X hay un único valor posible para Y. Simbólicamente se denota por X -> Y.
Por ejemplo el nombre de una persona depende funcionalmente del DNI; es decir para un DNI concreto sólo hay
un nombre posible. En la tabla del ejemplo anterior, el departamento no tiene dependencia funcional, ya que
para un mismo DNI puede haber más de un departamento posible. Pero el nombre sí que depende del DNI.
Al conjunto X del que depende funcionalmente el conjunto Y se le llama determinante. Al conjunto Y se le llama
implicado.
Dependencia funcional completa

Un conjunto de atributos (Y) tiene una dependencia funcional completa sobre otro conjunto de atributos (X) si
Y tiene dependencia funcional de X y además no se puede obtener de X un conjunto de atributos más pequeño
que consiga una dependencia funcional de Y (es decir, no hay en X un determinante formado por atributos más
pequeños).
Por ejemplo en una tabla de clientes, el conjunto de atributos formado por el nombre y el dni producen una
dependencia funcional sobre el atributo apellidos. Pero no es plena ya que el dni individualmente, también pro-
duce una dependencia funcional sobre apellidos. El dni sí produce una dependencia funcional completa sobre
el campo apellidos.
Una dependencia funcional completa se denota como X => Y
112
Base de Datos
Dependencia funcional elemental

Se produce cuando X e Y forman una dependencia funcional completa y además Y es un único atributo.
Dependencia funcional transitiva

Es más compleja de explicar, pero tiene también utilidad. Se produce cuando tenemos tres conjuntos de atributos
X, Y y Z. Y depende funcionalmente de X (X -> Y), Z depende funcionalmente de Y (Y -> Z). Además X no depende
funcionalmente de Y (Y-/ ->X). Entonces ocurre que X produce una dependencia funcional transitiva sobre Z.
Esto se denota como: (X - -> Z)
Por ejemplo si X es el atributo Número de Clase de un instituto, e Y es el atributo Código Profesor. Entonces X ->Y
(el Profesor depende funcionalmente del número de clase). Si Z representa el Código del departamento, enton-
ces Y -> Z (el código del departamento depende funcionalmente del código Profesor, cada Profesor sólo puede
estar en un departamento). Como ocurre que Y-/ -> X (el código de la clase no depende funcionalmente del códi-
go profesor, un código profesor se puede corresponder con varios códigos de clase). Entonces X - -> Z (el código
del departamento depende transitivamente del código de la clase).
Segunda forma normal - FN2

Ocurre si una tabla está en primera forma normal y además cada atributo que no sea clave, depende de forma
funcional completa respecto de cualquiera de las claves. Toda la clave principal debe hacer dependientes al resto
de atributos, si hay atributos que depende sólo de parte de la clave, entonces esa parte de la clave y esos atribu-
tos formarán otra tabla. Ejemplo:
Gráfico 79 – Tabla alumnos sin normalizar.
Suponiendo que el DNI y el código de curso formen una clave principal para esta tabla, sólo la nota tiene depen-
dencia funcional completa. El nombre y los apellidos dependen de forma completa del DNI. La tabla no es 2FN,
para arreglarlo:
Gráfico 80
Tabla alumnos
normalizada 2FN.

113
Tercera forma normal - FN3

Ocurre cuando una tabla está en 2FN y además ningún atributo que no sea clave depende transitivamente de las
claves de la tabla. Es decir no ocurre cuando algún atributo depende funcionalmente de atributos que no son clave.
Ejemplo:

Gráfico 81 – Tabla alumnos desnormalizada.
La provincia depende funcionalmente del código de provincia, lo que hace que no esté en 3FN. El arreglo sería:
Gráfico 82
Tabla alumnos
normalizada 3FN.

Forma Normal Boyce-Codd (BCNF or FNBC)

Ocurre si una tabla está en tercera forma normal y además todo determinante es una clave candidata. Ejemplo:
Gráfico 83
Tabla organización
desnormalizada.

114
Base de Datos
La cuestión es que un trabajador o trabajadora puede trabajar en varios departamentos. En dicho departamento
hay varios responsables, pero cada trabajador sólo tiene asignado uno. El detalle importante que no se ha tenido
en cuenta, es que el o la responsable sólo puede ser responsable en un departamento.
Este detalle último produce una dependencia funcional ya que:
Responsable -> Departamento
Por lo tanto hemos encontrado un determinante que no es clave candidata. No está por tanto en FNBC. En este
caso la redundancia ocurre por mala selección de clave. La redundancia del departamento es completamente
evitable. La solución sería:
Gráfico 84
Tabla organización
normalizada FNBC.
En las formas de Boyce-Codd hay que tener cuidado al descomponer ya que se podría perder información por
una mala descomposición.
Cuarta forma normal – FN4. Dependencias multivaluadas.

Para el resto de formas normales (las diseñadas por Fagin, mucho más complejas), es importante definir este tipo
de dependencia, que es distinta de las funcionales. Si las funcionales eran la base de la segunda y tercera forma
normal (y de la de Boyce-Codd), éstas son la base de la cuarta forma normal.
Una dependencia multivaluada de X sobre Y (es decir X->>Y), siendo X e Y atributos de la misma tabla, ocurre
cuando Y tiene un conjunto de valores bien definidos sobre cualquier valor de X. Es decir, dado X sabremos los
posibles valores que puede tomar Y.
115
Se refiere a posibles valores (en plural) y se trata de que los valores de ese atributo siempre son los mismos según
el valor de un atributo y no del otro.
Ejemplo:

Gráfico 85 – Tabla cursos.
La tabla cursos, profesores y materiales del curso. La tabla está en FNBC ya que no hay dependencias transitivas y
todos los atributos son clave sin dependencia funcional hacia ellos. Sin embargo hay redundancia. Los materiales
se van a repetir para cualquier profesor dando cualquier curso, ya que los profesores van a utilizar todos los ma-
teriales del curso (de no ser así no habría ninguna redundancia).
Los materiales del curso dependen de forma multivaluada del curso y no del profesor en una dependencia multi-
valuada (no hay dependencia funcional ya que los posibles valores son varios). Para el par Nº de curso y Profesor
podemos saber los materiales; pero lo sabemos por el curso y no por el profesor.
Cuarta forma normal

Ocurre esta forma normal cuando una tabla está en forma normal de Boyce Codd y toda dependencia multiva-
luada es una dependencia funcional. Para la tabla anterior la solución serían dos tablas:
Gráfico 86
Ejemplo FN4.

Gráfico 87
Ejemplo FN4.

116
Base de Datos
Un teorema de Fagin indica cuando hay tres pares de conjuntos de atributos X, Y y Z si ocurre X->>Y y X->>Z (Y y
Z tienen dependencia multivaluada sobre X), entonces las tablas X, Y y X, Z reproducen sin perder información lo
que poseía la tabla original. Este teorema marca la forma de dividir las tablas hacia una 4FN.
Quinta forma normal – FN5

Dependencias de join o reunión.
Una proyección de una tabla es la tabla resultante de tomar un subconjunto de los atributos de una tabla (se trata
de la operación proyección, P, del álgebra relacional). Es decir una tabla formada por unas cuantas columnas de
la tabla original.
La operación JOIN procedente también del álgebra relacional, consiste en formar una tabla con la unión de dos
tablas. La tabla resultante estará formada por la combinación de todas las columnas y filas de ambas, excepto las
columnas y filas repetidas.
Se dice que se tiene una tabla con dependencia de unión (o de tipo JOIN) si se puede obtener esa tabla como
resultado de combinar mediante la operación JOIN varias proyecciones de la misma.
Quinta forma normal forma de proyección reunión

Ocurre cuando una tabla está en 4FN y cada dependencia de unión (JOIN) en ella es implicada por las claves
candidatas.
Es la más compleja y polémica de todas. Polémica pues no está claro en muchas ocasiones está muy claro que el
paso a 5FN mejore la base de datos. Fue definida también por Fagin.
Es raro encontrarse este tipo de problemas cuando la normalización llega a 4FN. Se deben a restricciones semán-
ticas especiales aplicadas sobre la tabla.
Ejemplo:
Gráfico 88 – Ejemplo FN5
Indican códigos de material suministrado por un proveedor y utilizado en un determinado proyecto. Así vista la
tabla, no permite ninguna proyección en la que no perdamos datos.
Pero si ocurre una restricción especial como por ejemplo: Cuando un proveedor nos ha suministrado alguna vez
un determinado material, si ese material aparece en otro proyecto, haremos que el proveedor anterior nos sumi-
nistre también ese material para el proyecto.
Eso ocurre en los datos como el proveedor número 1 nos suministró el material número 1 para el proyecto 2 y en
el proyecto 1 utilizamos el material 1, aparecerá la
tupla proveedor 1, material 1 y proyecto 1. Si un nuevo proyecto necesitara el material 1, entonces habrá que
pedirlo a los proveedores 1 y 2 (ya que en otros proyectos les henos utilizado)
117
La dependencia de reunión que produce esta restricción es muy difícil de ver ya que es lejana. Para esa restricción
esta proyección de tablas sería válida:
Gráfico 89
Ejemplo FN5.

Esa descomposición no pierde valores en este caso, sabiendo que si el proveedor nos suministra un material po-
dremos relacionarle con todos los proyectos que utilizan ese material.
Resumiendo, una tabla no está en quinta forma normal si hay una descomposición de esa tabla que muestre la
misma información que la original y esa descomposición no tenga como clave la clave original de la tabla.
Resumen tema 12
Normalización
El principio fundamental reside en que las tablas deben referirse a objetos o situaciones muy concretas, relacio-
nados exactamente con elementos reconocibles por el sistema de información de forma inequívoca. Cada fila de
una tabla representa inequívocamente un elemento reconocible en el sistema. Lo que ocurre es que conceptual-
mente es difícil agrupar esos elementos correctamente.
Formas normales
Las formas normales se corresponde a una teoría de normalización iniciada por el propio Codd y continuada por
otros autores (entre los que destacan Boyce y Fagin). Codd definió en 1970 la primera forma normal, desde ese
momento aparecieron la segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma normal.
Hay que tener en cuenta que muchos diseñadores opinan que basta con llegar a la forma Boyce-Codd, ya que la
cuarta, y sobre todo la quinta, forma normal es polémica.
118
Base de Datos
Primera forma normal - FN1

Se dice que una tabla se encuentra en primera forma normal si impide que un atributo de una tupla pueda tomar
más de un valor.
Dependencia funcional
Se dice que un conjunto de atributos (Y) depende funcionalmente de otro conjunto de atributos (X) si para cada
valor de X hay un único valor posible para Y. Simbólicamente se denota por X -> Y.
Dependencia funcional completa

Y tiene dependencia funcional de X y además no se puede obtener de X un conjunto de atributos más pequeño
que consiga una dependencia funcional de Y (es decir, no hay en X un determinante formado por atributos más
pequeños).
Dependencia funcional elemental

Dependencia funcional transitiva

Es más compleja de explicar, pero tiene también utilidad. Se produce cuando tenemos tres conjuntos de atributos
X, Y y Z. Y depende funcionalmente de X (X -> Y), Z depende funcionalmente de Y (Y -> Z). Además X no depende
funcionalmente de Y (Y-/ ->X). Entonces ocurre que X produce una dependencia funcional transitiva sobre Z.
Segunda forma normal - FN2

funcional completa respecto de cualquiera de las claves. Toda la clave principal debe hacer dependientes al resto
de atributos, si hay atributos que depende sólo de parte de la clave, entonces esa parte de la clave y esos atribu-
tos formarán otra tabla.
Tercera forma normal - FN3

Ocurre cuando una tabla está en 2FN y además ningún atributo que no sea clave depende transitivamente de las
claves de la tabla. Es decir no ocurre cuando algún atributo depende funcionalmente de atributos que no son clave.
Forma Normal Boyce-Codd (BCNF or FNBC)

Ocurre si una tabla está en tercera forma normal y además todo determinante es una clave candidata.
En las formas de Boyce-Codd hay que tener cuidado al descomponer ya que se podría perder información por
una mala descomposición.
Cuarta forma normal – FN4. Dependencias multuvaluadas

Para el resto de formas normales (las diseñadas por Fagin, mucho más complejas), es importante definir este tipo
de dependencia, que es distinta de las funcionales. Si las funcionales eran la base de la segunda y tercera forma
normal (y de la de Boyce-Codd), éstas son la base de la cuarta forma normal.
Una dependencia multivaluada de X sobre Y (es decir X->>Y), siendo X e Y atributos de la misma tabla, ocurre
cuando Y tiene un conjunto de valores bien definidos sobre cualquier valor de X. Es decir, dado X sabremos los
posibles valores que puede tomar Y.
Quinta forma normal – FN5

Dependencias de join o reunión
Una proyección de una tabla es la tabla resultante de tomar un subconjunto de los atributos de una tabla (se trata
de la operación proyección, P, del álgebra relacional). Es decir una tabla formada por unas cuantas columnas de
la tabla original.
119
La operación JOIN procedente también del álgebra relacional, consiste en formar una tabla con la unión de dos
tablas. La tabla resultante estará formada por la combinación de todas las columnas y filas de ambas, excepto las
columnas y filas repetidas.
Se dice que se tiene una tabla con dependencia de unión (o de tipo JOIN) si se puede obtener esa tabla como
resultado de combinar mediante la operación JOIN varias proyecciones de la misma.
Ejercitación
Normalizar las siguientes tablas
Ejercicio 1
id_cliente nombre apellido contacto

1 jose garcia 47654222
2 enrique lopez 45367263
3 daniel perez 46736522, 43321234
Ejercicio 2
dni nombre apellido Mail

22111232 lucas garcia [email protected]
33432123 cesar lopez clopez@hotmail
43456987 daniel perz [email protected],
[email protected]
Ejercicio 3
id_gerente gerente direccion Localidad id_localidad

22 gonzalez sarmiento 11 Junin 1
43 ramirez jonte 322 Azul 2
23 estevez san martin 31 capitan sarmiento 3
44 garcia belgrano 54 Junin 1
Ejercicio 4
cod_libro titulo autor cod_editorial editorial

1 martin fierro j hernandez 2 lozada
2 la iliada homero 3 gredos
3 tragedias I herodoto 3 gredos
4 el facundo sarmiento 2 lozada
120
Base de Datos
Ejercicio 5
Vendedores
dni nombre apellido factura importe
22111232 lucas garcia 2231123 100
33432123 cesar lopez 1342342 200
43456987 daniel perz 24353245 104
33432123 cesar lopez 1342343 204
Ejercicio 6
Artículos
cod_art articulo descrip_art material cod_material
22111232 vaso azul por 6 unid plastico 123
33432123 plato playo pirex 124
43456987 botella verde vidrio 125
33432123 copa noruega agua vidrio 125
Investigación
1. Lea de Sistemas de base de datos – C.J. Date – Addison-Wesley Iberoamericana. Capitulo 21 - Normalización
adicional.
2. Lea de Organización de base de datos – James Martin. Prentice Hall. Capitulo 14 - Tercera forma normal.
121
122
Unidad 4

4. SQL, DDL y SML
Tema Nº 13
SQL, DDL y DML
Historia del SQL
El nacimiento del lenguaje SQL data de 1970 cuando E. F. Codd publica su libro: “Un modelo de datos relacional
para grandes bancos de datos compartidos”. Ese libro dictaría las direcrices de las bases de datos relacionales.
Apenas dos años después IBM (para quien trabajaba Codd) utiliza las directrices de Codd para crear el Standard
English Query Language (Lenguaje Estándar Inglés para Consultas) al que se le llamó SEQUEL. Más adelante se le
asignaron las siglas SQL (Standard Query Language, lenguaje estándar de consulta) aunque en inglés se siguen
pronunciando secuel. En español se pronuncia esecuele.
En 1979 Oracle presenta la primera implementación comercial del lenguaje. Poco después se convertía en un
estándar en el mundo de las bases de datos avalado por los organismos ISO y ANSI. En el año 1986 se toma como
lenguaje estándar por ANSI de los SGBD relacionales. Un año después lo adopta ISO, lo que convierte a SQL en
estándar mundial como lenguaje de bases de datos relacionales.
En 1989 aparece el estándar ISO (y ANSI) llamado SQL89 o SQL1. En 1992 aparece la nueva versión estándar de
SQL (a día de hoy sigue siendo la más conocida) llamada SQL92. En 1999 se aprueba un nuevo SQL estándar que
incorpora mejoras que incluyen triggers, procedimientos, funciones,… y otras características de las bases de da-
tos objeto-relacionales; dicho estándar se conoce como SQL99.
El último estándar es el del año 2008 (SQL2008).
Funcionamiento del SQL

Según la normativa ANSI/ISO cuando se ejecuta SQL, existen los siguientes elementos a tener en cuenta en todo
el entorno involucrado en la ejecución de instrucciones SQL:
• Un agente SQL. Entendido como cualquier elemento que cause la ejecución de instrucciones SQL que serán
recibidas por un cliente SQL
• Una implementación SQL. Se trata de un procesador software capaz de ejecutar las instrucciones pedidas
por el agente SQL. Una implementación está compuesta por:
- Un cliente SQL. Software conectado al agente que funciona como interfaz entre el agente SQL y el ser-
vidor SQL. Sirve para establecer conexiones entre sí mismo y el servidor SQL.
- Un servidor SQL (puede haber varios). El software encargado de manejar los datos a los que la instruc-
ción SQL lanzada por el agente hace referencia. Es el software que realmente realiza la instrucción, los
datos los devuelve al cliente.
Ejecución directa sql interactivo

Las instrucciones SQL se introducen a través de un cliente que está directamente conectado al servidor SQL; por
lo que las instrucciones se traducen sin intermediarios y los resultados se muestran en el cliente.
Normalmente es un modo de trabajo incómodo, pero permite tener acceso a todas las capacidades del lenguaje
SQL de la base de datos a la que estamos conectados.
Ejecución embebida
Las instrucciones SQL se colocan como parte del código de otro lenguaje que se considera host (C, Java, Pascal,
Visual Basic,...). Al compilar el código se utiliza un precompilador de la propia base de datos para traducir el SQL
y conectar la aplicación resultado con la base de datos a través de un software adaptador (driver) como JDBC u
ODBC por ejemplo.
124
Base de Datos
Ejecución entre cliente gráficos

Se trata de software que permite conectar a la base de datos a través de un cliente. El software permite manejar
de forma gráfica la base de datos y las acciones realizadas son traducidas a SQL y enviadas al servidor. Los resul-
tados recibidos vuelven a ser traducidos de forma gráfica para un manejo más cómodo
Ejecución dinámica
Se trata de SQL incrustado en módulos especiales que pueden ser invocados una y otra vez desde distintas apli-
caciones.
Proceso de las instrucciones

El proceso de una instrucción SQL es el siguiente:
• Se analiza la instrucción. Para comprobar la sintaxis de la misma

• Si es correcta se valora si los metadatos de la misma son correctos. Se comprueba esto en el diccionario de
datos.
• Si es correcta, se optimiza, a fin de consumir los mínimos recursos posibles.
• Se ejecuta la sentencia y se muestra el resultado al emisor de la misma.
Elementos del lenguaje SQL

El código SQL consta de los siguientes elementos:
1. Comandos. Las distintas instrucciones que se pueden realizar desde SQL.
• SELECT. Se trata del comando que permite realizar consultas sobre los datos de la base de datos. Obtiene
datos de la base de datos. A ésta parte del lenguaje se la conoce como DQL (Data Query Language, Lengua-
je de consulta de datos); pero es parte del DML del lenguaje.
• DML, Data Manipulation Language (Lenguaje de manipulación de datos). Modifica filas (registros) de la
base de datos. Lo forman las instrucciones INSERT, UPDATE, MERGE y DELETE.
• DDL, Data Definition Language (Lenguaje de definición de datos). Permiten modificar la estructura de las
tablas de la base de datos. Lo forman las instrucciones CREATE, ALTER, DROP, RENAME y TRUNCATE.
• DCL, Data Control Language (Lenguaje de control de datos). Administran los derechos y restricciones de los
usuarios. Lo forman las instrucciones GRANT y REVOKE.
• Instrucciones de control de transacciones (DTL). Administran las modificaciones creadas por las instruccio-
nes DML. Lo forman las instrucciones ROLLBACK y COMMIT. Se las considera parte del DML.
2. Cláusulas. Son palabras especiales que permiten modificar el funcionamiento de un comando (WHERE, ORDER BY,…).
3. Operadores. Permiten crear expresiones complejas. Pueden ser aritméticos (+,-,*,/,...) lógicos (>, <, !=,<>, AND, OR,...).
4. Funciones. Para conseguir valores complejos (SUM(), DATE(),...) .
5. Literales. Valores concretos para las consultas: números, textos, caracteres,... Ejemplos: 2, 12.34, ‘Avda Cardenal
Cisneros’.
6. Metadatos. Obtenidos de la propia base de datos.
125
DDL
El DDL es la parte del lenguaje SQL que realiza la función de definición de datos del SGBD. Fundamentalmente se
encarga de la creación, modificación y eliminación de los objetos de la base de datos (es decir de los metadatos).
Por supuesto es el encargado de la creación de las tablas.
Cada usuario de una base de datos posee un esquema. El esquema suele tener el mismo nombre que el usuario
y sirve para almacenar los objetos de esquema, es decir los objetos que posee el usuario.
Esos objetos pueden ser: tablas, vistas, índices y otros objetos relacionados con la definición de la base de datos.
Los objetos son manipulados y creados por los usuarios. En principio sólo los administradores y los usuarios pro-
pietarios pueden acceder a cada objeto, salvo que se modifiquen los privilegios del objeto para permitir el acceso
a otros usuarios.
Hay que tener en cuenta que ninguna instrucción DDL puede ser anulada por una instrucción ROLLBACK. Es de-
cir, las instrucciones DDL generan acciones que no se pueden deshacer (salvo que dispongamos de alguna copia
de seguridad).
Creación de base de datos

Esta es una tarea administrativa que se comentará más profundamente en otros temas. Por ahora sólo se co-
menta de forma simple. Crear la base de datos implica indicar los archivos y ubicaciones que se utilizarán para la
misma, además de otras indicaciones técnicas y administrativas que no se comentarán en este tema.
El comando SQL de creación de una base de datos es CREATE DATABASE. Este comando crea una base de datos
con el nombre que se indique. Ejemplo:
CREATE DATABASE prueba;
Pero normalmente se indican más parámetros.
CREATE DATABASE prueba

LOGFILE prueba.log
MAXLOGFILES 25
MAXINSTANCES 10
ARCHIVELOG
CHARACTER SET WIN1214
NATIONAL CHARACTER SET UTF8
DATAFILE prueba1.dbf AUTOEXTEND ON MAXSIZE 500MB;
Objetos de la base de datos

Según los estándares actuales, una base de datos es un conjunto de objetos pensados para gestionar datos. Estos
objetos están contenidos en esquemas, los esquemas suelen estar asociados al perfil de un usuario en particular.
En el estándar SQL existe el concepto de catálogo que sirve para almacenar esquemas. Así el nombre completo
de un objeto vendría dado por: catálogo.esquema.objeto.
Si no se indica el catálogo se toma el catálogo por defecto. Si no se indica el esquema se entiende que el objeto
está en el esquema actual.
Creación de tablas
Es la orden SQL que permite crear una tabla. Por defecto será almacenada en el espacio y esquema del usuario
que crea la tabla. Sintaxis:
CREATE TABLE [esquema.] nombreDeTabla

(nombreDeLaColumna1 tipoDeDatos [, ...]);
Ejemplo:
CREATE TABLE proveedores (nombre VARCHAR(25));
126
Base de Datos
Crea una tabla con un solo campo de tipo VARCHAR.

Sólo se podrá crear la tabla si el usuario posee los permisos necesarios. Si la tabla pertenece a otro esquema
(suponiendo que el usuario tenga permiso para grabar tablas en ese otro esquema), se antepone al nombre de
la tabla, el nombre del esquema:
CREATE TABLE otroUsuario.proveedores (nombre VARCHAR(25));
Tipos de datos
A la hora de crear tablas, hay que indicar el tipo de datos de cada campo. Necesitamos pues conocer los distintos
tipos de datos.
Gráfico 83
Tipos de datos numéricos.

Gráfico 84
Tipos de datos texto.

127

Gráfico 85 – Tipos de datos fecha.
Gráfico 86 – Tipos de datos booleanos y binarios.
Blob - Binary large object

Los BLOB (Binary Large OBjects, objetos binarios grandes) son elementos utilizados en las bases de datos para
almacenar datos de gran tamaño que cambian de forma dinámica. No todos los Sistemas Gestores de Bases de
Datos son compatibles con los BLOB.
Generalmente, estos datos son imágenes, archivos de sonido y otros objetos multimedia; a veces se almacenan
como BLOB código de binarios.
El término blob se refería originalmente a pedazos amorfos de código, y fue inventado por Jim Starkey. Con el
tiempo, Terry McKiever, un encargado de mercadotecnia, ideó un acrónimo: Basic Large OBject (objeto grande
básico). Pero fue Informix quien ideó el actual acrónimo para BLOB.
El tipo de dato y su definición se introdujeron para representar datos que anteriormente no estaban definidos en
las bases de datos para computadoras, pero que se hicieron posible al abaratarse los discos de almacenamiento.
Dominio
En SQL es posible especificar directamente el tipo de dato para cada atributo, como se mostró en el ejemplo an-
terior. Pero también se pueden declarar dominios, y usar el nombre de éstos. Esto facilita hacer cambios en los
tipos de datos (cambiando sólo el dominio y no cada dato declarado). Por ejemplo, podemos crear el dominio
TIPO_RUT con la siguiente instrucción:
CREATE DOMAIN TIPO_RUT AS VARCHAR(10);
128
Base de Datos
Modificación – Alter
Este comando permite modificar la estructura de un objeto- Se pueden agregar / quitar campos a una tabla, mo-
dificar el tipo de un campo, agregar / quitar índices a una tabla, modificar un trigger, etc.
Ejemplo 1 (renombrar una tabla):
ALTER TABLE nombre Viejo RENAME TO nombre Nuevo;
Ejemplo 2 (agregar una columna):
ALTER TABLE nombreTabla ADD(nombreColumna TipoDatos [Propiedades]

[,columnaSiguiente tipoDatos [propiedades]...)
Permite añadir nuevas columnas a la tabla. Se deben indicar su tipo de datos y sus propiedades si es necesario
(al estilo de CREATE TABLE). Las nuevas columnas se añaden al final, no se puede indicar otra posición (hay que
recordar que el orden de las columnas no importa).
Eliminación – Drop
Este comando elimina un objeto de la base de datos. Puede ser una tabla, vista, índice, trigger, función, proce-
dimiento o cualquier otro objeto que el motor de la base de datos soporte. Se puede combinar con la sentencia
ALTER.
Ejemplo 1:
DROP TABLE tabla nombre
Ejemplo 2:
ALTER TABLE nombre Tabla DROP(columna [,columnaSiguiente,...]);
Elimina la columna indicada de manera irreversible e incluyendo los datos que contenía.
Restricciones
Una restricción es una condición de obligado cumplimiento para una o más columnas de la tabla. A cada res-
tricción se le pone un nombre, en el caso de no poner un nombre (algo poco recomendable) entonces el propio
SGBD le coloca el nombre que es un mnemotécnico con el nombre de tabla, columna y tipo de restricción.
Restricciones PRIMARY KEY
• Una tabla puede contener una sola restricción PRIMARY KEY.

• El índice generado por una restricción PRIMARY KEY no puede hacer que el número de índices de la tabla
exceda de 249 índices no agrupados y 1 índice agrupado.
• Si no se especifica CLUSTERED o NONCLUSTERED para una restricción PRIMARY KEY, se utiliza CLUSTERED si
no hay índices agrupados especificados para las restricciones UNIQUE.
• Todas las columnas definidas en una restricción PRIMARY KEY deben establecerse como NOT NULL. Si no
se especifica la posibilidad de aceptar NULL, todas las columnas que participan en una restricción PRIMARY
KEY tienen su posibilidad de aceptar NULL establecida en NOT NULL.
129
Restricciones UNIQUE
• Si no se especifica CLUSTERED o NONCLUSTERED para una restricción UNIQUE, de manera predeterminada
se utiliza NONCLUSTERED.
• Cada restricción UNIQUE genera un índice. El número de restricciones UNIQUE no puede hacer que el nú-
mero de índices de la tabla exceda de 249 índices no agrupados y 1 índice agrupado.
Restricciones FOREIGN KEY

• Cuando en la columna de una restricción FOREIGN KEY se introduce un valor distinto de NULL, el valor debe
existir en la columna a la que se hace referencia; de lo contrario, se devuelve un mensaje de error de infrac-
ción de clave externa.
• Las restricciones FOREIGN KEY se aplican a la columna anterior a menos que se especifiquen columnas de
origen.
• Las restricciones FOREIGN KEY sólo pueden hacer referencia a las tablas de la misma base de datos en el
mismo servidor. La integridad referencial de las bases de datos cruzadas debe implementarse a través de
desencadenadores. Las restricciones FOREIGN KEY pueden hacer referencia a otras columnas de la misma
tabla (una auto-referencia).
• La cláusula REFERENCES de una restricción FOREIGN KEY en el nivel de columna puede enumerar sólo una co-
lumna de referencia, que debe tener el mismo tipo de datos que la columna en la que se define la restricción.
• La cláusula REFERENCES de una restricción FOREIGN KEY en el nivel de tabla debe tener el mismo número
de columnas de referencia que el número de columnas de la lista de columnas de restricción. El tipo de da-
tos de cada columna de referencia debe ser también el mismo que la columna correspondiente de la lista
de columnas.
• Es posible que no se pueda especificar CASCADE si una columna del tipo timestamp forma parte de la clave
externa o de la clave a la que se hace referencia.
• Se puede combinar CASCADE y NO ACTION en tablas que tengan relaciones referenciales entre sí. Si SQL
Server encuentra NO ACTION, termina y deshace las acciones CASCADE relacionadas. Cuando una instruc-
ción DELETE hace que se combinen acciones CASCADE y NO ACTION, todas las acciones CASCADE se apli-
can antes de que SQL Server compruebe si hay cláusulas NO ACTION.
• Una tabla puede contener un máximo de 253 restricciones FOREIGN KEY.
• Las restricciones FOREIGN KEY sólo pueden hacer referencia a las columnas de las restricciones PRIMARY
KEY o UNIQUE de la tabla de referencia o a las columnas en UNIQUE INDEX de la tabla de referencia.
Definiciones DEFAULT
• Una columna sólo puede tener una definición DEFAULT.
• Una definición DEFAULT puede contener valores constantes, funciones, funciones niládicas SQL-92 o NULL.
La tabla muestra las funciones niládicas y los valores que devuelven para el valor predeterminado durante
la ejecución de una instrucción INSERT.
• En una definición DEFAULT, constant_expression no puede hacer referencia a otra columna de la tabla o a
otras tablas, vistas o procedimientos almacenados.
• Las definiciones DEFAULT no se pueden crear sobre columnas con un tipo de datos timestamp o columnas
con una propiedad IDENTITY.
• Las definiciones DEFAULT no se pueden crear para columnas con tipos de datos definidos por el usuario, si
éstos están enlazados a un objeto predeterminado.
130
Base de Datos
Restricciones CHECK
• Una columna puede tener cualquier número de restricciones CHECK y la condición puede incluir varias
expresiones lógicas combinadas con AND y OR. Varias restricciones CHECK para una columna se validan en
el orden en que se crean.
• La condición de búsqueda debe dar como resultado una expresión booleana y no puede hacer referencia a
otra tabla.
• Una restricción CHECK en el nivel de columna sólo puede hacer referencia a la columna restringida, y una
restricción CHECK en el nivel de tabla sólo puede hacer referencia a columnas de la misma tabla.
Las restricciones CHECK y las reglas sirven para la misma función de validación de los datos durante las ins-
trucciones INSERT y DELETE.
• Cuando hay una regla y una o más restricciones CHECK para una columna o columnas, se evalúan todas las
restricciones.
Reglas que aceptan valores NULL en la definición de una tabla

La aceptación de valores NULL en una columna determina si esa columna permite valores nulos (NULL) como
datos de la columna. NULL no es lo mismo que cero o en blanco: significa que no se ha realizado ninguna entrada
ni que se ha suministrado explícitamente un valor NULL y, normalmente, implica que el valor es desconocido o
no es aplicable.
Cuando cree o altere una tabla con las instrucciones CREATE TABLE o ALTER TABLE, los valores de sesión y de la
base de datos influirán y, posiblemente, anularán la posibilidad de aceptar NULL para el tipo de datos utilizado en
la definición de una columna. Se recomienda que defina siempre explícitamente una columna como NULL o NOT
NULL, en el caso de columnas no calculadas, o si utiliza un tipo de datos definido por el usuario, que permita a la
columna emplear la posibilidad de aceptar el valor NULL predeterminada del tipo de datos.
Cuando no se especifica explícitamente, la posibilidad de aceptar el valor NULL de una columna sigue estas reglas:
• Si la columna se define con un tipo de datos definido por el usuario:
- SQL Server utiliza la posibilidad de aceptar el valor NULL especificada cuando se creó el tipo de datos.
Utilice sp_help para obtener la posibilidad de aceptar el valor NULL predeterminada del tipo de datos.
• Si la columna se ha definido con un tipo de datos suministrado por el sistema:
- Si el tipo de datos suministrado por el sistema sólo tiene una opción, ésta tiene precedencia. Los tipos
de datos timestamp deben ser NOT NULL.
- Si el valor de sp_dbcmptlevel es 65 o inferior, el valor del tipo de datos bit es, de manera predetermi-
nada, NOT NULL si la columna no tiene un NULL o NOT NULL explícito
- Si alguno de los valores de la sesión es ON (activado con la instrucción SET), entonces:
Si ANSI_NULL_DFLT_ON es ON, se asigna NULL.
Si ANSI_NULL_DFLT_OFF es ON, se asigna NOT NULL.
- Si hubiera configurado algún valor de la base de datos (cambiado con sp_dboption), entonces:
Si ANSI null default es true (verdadero), se asigna NULL.
Si ANSI null default es false (falso), se asigna NOT NULL.
• Cuando ninguna de las opciones ANSI_NULL_DFLT está establecida para la sesión y la base de datos tiene
los valores predeterminados (ANSI null default es false), se asigna el valor predeterminado NOT NULL de
SQL Server.
• Si la columna es una columna calculada, SQL Server determinará automáticamente si se aceptan valores
NULL. Utilice la función COLUMNPROPERTY (propiedad AllowsNull) para saber si la columna acepta valores
NULL.
131
Resumen tema 13
Funcionamiento del SQL
Según la normativa ANSI/ISO cuando se ejecuta SQL, existen los siguientes elementos a tener en cuenta en todo
el entorno involucrado en la ejecución de instrucciones SQL:
a. Un agente SQL. Entendido como cualquier elemento que cause la ejecución de instrucciones SQL.
b. Una implementación SQL. Se trata de un procesador software capaz de ejecutar las instrucciones.
• Ejecución directa sql interactivo: las instrucciones SQL se introducen a través de un cliente que está directa-
mente conectado al servidor SQL.
• Ejecución embebida: las instrucciones SQL se colocan como parte del código de otro lenguaje. Al compilar
el código se utiliza un precompilador de la propia base de datos para traducir el SQL y conectar la aplicación
resultado con la base de datos por medio de un ODBC.
• Ejecución entre cliente gráficos: se trata de software que permite conectar a la base de datos a través de un
cliente.
• Ejecución dinámica: se trata de SQL incrustado en módulos especiales que pueden ser invocados una y otra
vez desde distintas aplicaciones.
Proceso de las instrucciones.

1. Se analiza la instrucción. Para comprobar la sintaxis de la misma
2. Si es correcta se valora si los metadatos de la misma son correctos.
3. Si es correcta, se optimiza, a fin de consumir los mínimos recursos posibles.
4. Se ejecuta la sentencia y se muestra el resultado al emisor de la misma.
Elementos del lenguaje SQL

El código SQL consta de los siguientes elementos:
1. Comandos. Las distintas instrucciones que se pueden realizar desde SQL.
•DML, Data Manipulation Language (Lenguaje de manipulación de datos). INSERT, UPDATE, MERGE y DELETE.
•DDL, Data Definition Language (Lenguaje de definición de datos). CREATE, ALTER, DROP y RENAME.
•DCL, Data Control Language (Lenguaje de control de datos). GRANT y REVOKE.
•Instrucciones de control de transacciones (DTL).DML. ROLLBACK y COMMIT. Se las considera parte del DML.
2. Cláusulas. Son palabras especiales que permiten modificar el funcionamiento de un comando (WHERE,
ORDER BY,...).
3. Operadores. Permiten crear expresiones complejas. Pueden ser aritméticos (+,-,*,/,...) lógicos (>, <, !=,<>,
AND, OR,...).
4.Funciones. Para conseguir valores complejos (SUM(), DATE(),...) .
5. Literales. Valores concretos para las consultas: números, textos, caracteres,... Ejemplos: 2, 12.34, ‘Avda. Car-
denal Cisneros’.
6. Metadatos. Obtenidos de la propia base de datos.
132
Base de Datos
DDL
El DDL es la parte del lenguaje SQL que realiza la función de definición de datos del SGBD. Fundamentalmente se
encarga de la creación, modificación y eliminación de los objetos de la base de datos.
Creación de objetos
Creación de base de datos

El comando SQL de creación de una base de datos es CREATE DATABASE.
CREATE DATABASE prueba;
Creación de tablas
Es la orden SQL que permite crear una tabla.
CREATE TABLE [esquema.] nombre De Tabla
(nombreDeLaColumna1 tipo De Datos [, ...]);
Dominio
En SQL es posible declarar dominios, y usar el nombre de éstos. Esto facilita hacer cambios enlos tipos de
datos (cambiando sólo el dominio y no cada dato declarado).
CREATE DOMAIN TIPO_RUT AS VARCHAR(10);
Modificación de objetos
Este comando permite modificar la estructura de un objeto- Se pueden agregar / quitar campos a una tabla, etc.
Modificar tabla
ALTER TABLE nombre Viejo RENAME TO nombre Nuevo;
Eliminación de objetos
Este comando elimina un objeto de la base de datos.
Eliminar tabla.
DROP TABLE tabla_nombre
Eliminar columna.
ALTER TABLE nombreTabla DROP(columna [,columnaSiguiente,.]);
Restricciones
Una restricción es una condición de obligado cumplimiento para una o más columnas de la tabla.
1. Restricciones PRIMARY KEY.

2. Restricciones FOREIGN KEY.
3. Definiciones DEFAULT.
4. Restricciones CHECK.
5. Reglas que aceptan valores NULL en la definición de una tabla.
133
Ejercitación
1. Escribir la sintaxis para crear una base de datos llamada RRHH.
2. Escribir la sintaxis para crear la tabla empleados con los campos DNI numérico de 8, nombre carácter de 50,
apellido carácter 50.
3. Escribir la sintaxis para modificar la tabla empleados y agregar la columna teléfono numérico de 20.
4. Escribir la sintaxis para modificar de la tabla empleados el campo DNI y definirlo como clave primaria.
5. Escribir la sintaxis para crear la tabla salarios con los campos categoría carácter de 50, descripción carácter de
50, importe decimal de 8 enteros y 2 decimales.
6. Escribir la sintaxis para borrar la columna descripción de la tabla salarios.
7. Escribir las sintaxis para borrar las tablas empleados y salarios.
8. Escribir las sintaxis para borrar la base RRHH.
Investigación
1. Investigue los tipos de datos en http://msdn.microsoft.com/es-es/library/ms187752.aspx
2. Indague sobre lenguaje sql en http://www.sqlserverya.com.ar
3. Leo el Diseño de sistemas de Información - Burch J.G., Grudnistki G. Ed. Megabyte. Capitulo 8 Calculo relacional,
Quel y Qbe
134
Base de Datos
Tema Nº 14
DML
Es una de las partes fundamentales del lenguaje SQL. El DML (Data Manipulation Language) lo forman las instruc-
ciones capaces de modificar los datos de las tablas. Al conjunto de instrucciones DML que se ejecutan consecu-
tivamente, se las llama transacciones y se pueden anular todas ellas o aceptar, ya que una instrucción DML no es
realmente efectuada hasta que no se acepta (COMMIT).
Inserción
La adición de datos a una tabla se realiza mediante la instrucción INSERT. Su sintaxis fundamental es:
INSERT INTO tabla [(listaDeCampos)]

VALUES (valor1 [,valor2 ...])
La tabla representa la tabla a la que queremos añadir el registro y los valores que siguen a VALUES son los valo-
res que damos a los distintos campos del registro. Si no se especifica la lista de campos, la lista de valores debe
seguir el orden de las columnas según fueron creados (es el orden de columnas según las devuelve el comando
DESCRIBE).
La lista de campos a rellenar se indica si no queremos rellenar todos los campos. Los campos no rellenados ex-
plícitamente con la orden INSERT, se rellenan con su valor por defecto (DEFAULT) o bien con NULL si no se indicó
valor alguno. Si algún campo tiene
restricción de obligatoriedad (NOT NULL), ocurrirá un error si no rellenamos el campo con algún valor.
Por ejemplo, supongamos que tenemos una tabla de clientes cuyos campos son: dni, nombre, apellido1, ape-
llido2, localidad y dirección; supongamos que ese es el orden de creación de los campos de esa tabla y que la
localidad tiene como valor por defecto Palencia y la dirección no tiene valor por defecto. En ese caso estas dos
instrucciones son equivalentes:
INSERT INTO clientes VALUES( ‘11111111’,’Pedro’,’Gutiérrez’,

‘Crespo’,DEFAULT,NULL);
INSERT INTO clientes(dni,nombre,apellido1,apellido2)

VALUES(‘11111111’,’Pedro’,’Gutiérrez’, ‘Crespo’);
Son equivalentes puesto que en la segunda instrucción los campos no indicados se rellenan con su valor por de-
fecto y la dirección no tiene valor por defecto. La palabra DEFAULT fuerza a utilizar ese valor por defecto.
El uso de los distintos tipos de datos debe de cumplir los requisitos ya comentados en apartados anteriores.
Actualización
La modificación de los datos de los registros lo implementa la instrucción UPDATE.
Sintaxis:
UPDATE tabla
SET columna1=valor1 [,columna2=valor2...]
[WHERE condición]
Se modifican las columnas indicadas en el apartado SET con los valores indicados. La cláusula WHERE permite
especificar qué registros serán modificados.
135
Ejemplos:
UPDATE clientes SET provincia=’Ourense’

WHERE provincia=’Orense’;
UPDATE productos SET precio=precio*1.16;
El primer dato actualiza la provincia de los clientes de Orense para que aparezca como Ourense.
El segundo UPDATE incrementa los precios en un 16%. La expresión para el valor puede ser todo lo compleja que
se desee (en el ejemplo se utilizan funciones de fecha para conseguir que los partidos que se juagaban hoy, pasen
a jugarse el martes):
UPDATE partidos SET fecha= NEXT_DAY(SYSDATE,’Martes’)

WHERE fecha=SYSDATE;
Borrados de registros
Se realiza mediante la instrucción DELETE:
DELETE [FROM] tabla

[WHERE condición]
Es más sencilla que las anteriores, elimina los registros de la tabla que cumplan la condición indicada. Ejemplo:
DELETE FROM empleados

WHERE seccion=23;
Hay que tener en cuenta que el borrado de un registro no puede provocar fallos de integridad y que la opción de
integridad ON DELETE CASCADE hace que no sólo se borren los registros indicados en el SELECT, sino todos los
relacionados.
Instrucciones de control de transacciones (DTL)
Commit
La instrucción COMMIT hace que los cambios realizados por la transacción sean definitivos, irrevocables. Sólo se
debe utilizar si estamos de acuerdo con los cambios, conviene asegurarse mucho antes de realizar el COMMIT ya
que las instrucciones ejecutadas pueden afectar a miles de registros.
Además el cierre correcto de la sesión da lugar a un COMMIT, aunque siempre conviene ejecutar explícitamente
esta instrucción a fin de asegurarnos de lo que hacemos.
Rollback
Esta instrucción regresa a la instrucción anterior al inicio de la transacción, normalmente el último COMMIT, la
última instrucción DDL o DCL o al inicio de sesión.
Anula definitivamente los cambios, por lo que conviene también asegurarse de esta operación.
Un abandono de sesión incorrecto o un problema de comunicación o de caída del sistema dan lugar a un ROLL-
BACK implícito.
136
Base de Datos
Estado de los datos mientras la transacción

Si se inicia una transacción usando comandos DML hay que tener en cuenta que:
• Se puede volver a la instrucción anterior a la transacción cuando se desee.

• Las instrucciones de consulta SELECT realizadas por el usuario que inició la transacción muestran los datos
ya modificados por las instrucciones DML
• El resto de usuarios ven los datos tal cual estaban antes de la transacción, de hecho los registros afectados
por la transacción aparecen bloqueados hasta que la transacción finalice. Esos usuarios no podrán modifi-
car los valores de dichos registros.
• Tras la transacción todos los usuarios ven los datos tal cual quedan tras el fin de transacción. Los bloqueos
son liberados y los puntos de ruptura borrados.
Consultas de datos con SQL - DQL

DQL es la abreviatura del Data Query Language (lenguaje de consulta de datos) de SQL. El único comando que
pertenece a este lenguaje es el versátil comando SELECT
Este comando permite:
• Obtener datos de ciertas columnas de una tabla (proyección)

• Obtener registros (filas) de una tabla de acuerdo con ciertos criterios (selección)
• Mezclar datos de tablas diferentes (asociación, join)
• Realizar cálculos sobre los datos
• Agrupar datos
Sintaxis:
SELECT * | {[DISTINCT] columna | expresión [[AS] alias], ...}
FROM tabla;
Donde
• *. El asterisco significa que se seleccionan todas las columnas

• DISTINCT. Hace que no se muestren los valores duplicados.
• columna. Es el nombre de una columna de la tabla que se desea mostrar
• expresión. Una expresión válida SQL
• alias. Es un nombre que se le da a la cabecera de la columna en el resultado de esta instrucción.
Ejemplos:
/* Selección de todos los registros de la tabla clientes */
SELECT * FROM Clientes;
/* Selección de algunos campos*/

SELECT nombre, apellido1, apellido2 FROM Clientes;
Cálculo
Los operadores + (suma), - (resta), * (multiplicación) y / (división), se pueden utilizar para hacer cálculos en las
consultas. Cuando se utilizan como expresión en una consulta SELECT, no modifican los datos originales sino que
como resultado de la vista generada
por SELECT, aparece un nueva columna.
137
Ejemplo:
SELECT nombre, precio,precio*1.21 FROM articulos;
Esa consulta obtiene tres columnas. La tercera tendrá como nombre la expresión utilizada, para poner un alias
basta utilizar dicho alias tras la expresión:
SELECT nombre, precio, precio*1.21 AS precio_con_iva

FROM artículos;
La prioridad de esos operadores es la normal: tienen más prioridad la multiplicación y división, después la suma
y la resta. En caso de igualdad de prioridad, se realiza primero la operación que esté más a la izquierda. Como es
lógico se puede evitar cumplir esa prioridad usando paréntesis; el interior de los paréntesis es lo que se ejecuta
primero.
Cuando una expresión aritmética se calcula sobre valores NULL, el resultado es el propio valor NULL.
Se puede utilizar cualquiera de los operadores aritméticos: suma (+), resta (-), multiplicación (*), división (/). Como
es habitual, la multiplicación y la división tienen preferencia sobre la suma y la resta en el orden de ejecución de
la instrucción; dicho orden se puede alterar mediante el uso de los paréntesis.
Condiciones
Se pueden realizar consultas que restrinjan los datos de salida de las tablas. Para ello se utiliza la cláusula WHERE.
Esta cláusula permite colocar una condición que han de cumplir todos los registros, los que no la cumplan no
aparecen en el resultado.
Ejemplo:
SELECT Tipo, Modelo FROM Pieza WHERE Precio>3;

Gráfico 87 – Operadores de comparación.
138
Base de Datos
Gráfico 88 – Operadores lógicos.
Ejemplos:
/* Obtiene a las personas de entre 25 y 50 años*/
SELECT nombre, apellido1,apellido2 FROM personas
WHERE edad>=25 AND edad<=50;
Between
El operador BETWEEN nos permite obtener datos que se encuentren en un rango. Uso:
SELECT tipo,modelo,precio FROM piezas
WHERE precio BETWEEN 3 AND 8;
Saca piezas cuyos precios estén entre 3 y 8 (ambos incluidos).
In
Permite obtener registros cuyos valores estén en una lista de valores:
SELECT tipo,modelo,precio FROM piezas
WHERE precio IN (3,5, 8);
Obtiene piezas cuyos precios sean 3, 5 u 8 (no valen ni el precio 4 ni el 6, por ejemplo).
Like
Se usa sobre todo con textos, permite obtener registros cuyo valor en un campo cumpla una condición textual.
LIKE utiliza una cadena que puede contener estos símbolos:

Gráfico 89 – Operador like.
Ejemplos:
/* Selecciona nombres que empiecen por S */
SELECT nombre FROM personas WHERE nombre LIKE ‘S%’;
139
Is null
Devuelve verdadero si el valor que examina es nulo:
SELECT nombre,apellidos FROM personas

WHERE telefono IS NULL
Esa instrucción selecciona a la gente que no tiene teléfono. Se puede usar la expresión IS NOT NULL que devuelve
verdadero en el caso contrario, cuando la expresión no es nula.
Agrupaciones
Es muy común utilizar consultas en las que se desee agrupar los datos a fin de realizar cálculos en vertical, es decir
calculados a partir de datos de distintos registros. Para ello se utiliza la cláusula GROUP BY que permite indicar en
base a qué registros se realiza la agrupación. Con GROUP BY la instrucción SELECT queda de esta forma:
SELECT listaDeExpresiones
FROM listaDeTablas
[JOIN tablasRelacionadasYCondicionesDeRelación]
[WHERE condiciones]
[GROUP BY grupos]
[HAVING condicionesDeGrupo]
[ORDER BY columnas];
En el apartado GROUP BY, se indican las columnas por las que se agrupa. La función de este apartado es crear un
único registro por cada valor distinto en las columnas del grupo. Si por ejemplo agrupamos en base a las colum-
nas tipo y modelo en una tabla de
existencias, se creará un único registro por cada tipo y modelo distintos:
SELECT tipo,modelo
FROM existencias
GROUP BY tipo,modelo;
Funciones cálculo de grupo

Lo interesante de la creación de grupos es las posibilidades de cálculo que ofrece. Para ello se utilizan funciones
que permiten trabajar con los registros de un grupo son:
Gráfico 94
Funciones
del group by

140
Base de Datos
Todas las funciones de la tabla anterior se calculan para cada elemento del grupo, así la expresión:
SELECT tipo,modelo, cantidad, SUM(Cantidad)

FROM existencias
Cláusula Having
A veces se desea restringir el resultado de una expresión agrupada, por ejemplo con:
SELECT tipo,modelo, cantidad, SUM(Cantidad)

FROM existencias
WHERE SUM(Cantidad)>500
HAVING SUM(Cantidad)>500;
En definitiva, el orden de ejecución de la consulta marca lo que se puede utilizar con WHERE y lo que se puede
utilizar con HAVING:
Para evitar problemas estos podrían ser los pasos en la ejecución de una instrucción de agrupación por parte del
gestor de bases de datos.
Resumen tema 14
DML
Es una de las partes fundamentales del lenguaje SQL. El DML (Data Manipulation Language) lo forman las instruc-
ciones capaces de modificar los datos de las tablas.
Inserción
La adición de datos a una tabla se realiza mediante la instrucción INSERT.
INSERT INTO tabla [(listaDeCampos)]

VALUES (valor1 [,valor2 ...])
La tabla representa la tabla a la que queremos añadir el registro y los valores que siguen a VALUES son los valo-
res que damos a los distintos campos del registro. Si no se especifica la lista de campos, la lista de valores debe
seguir el orden de las columnas según fueron creados (es el orden de columnas según las devuelve el comando
DESCRIBE).
Actualización
La modificación de los datos de los registros lo implementa la instrucción UPDATE.
Sintaxis:
UPDATE tabla
SET columna1=valor1 [,columna2=valor2...]
[WHERE condición]
Se modifican las columnas indicadas en el apartado SET con los valores indicados. La cláusula WHERE permite
especificar qué registros serán modificados.
141
Borrados de registros
Se realiza mediante la instrucción DELETE:
DELETE [FROM] tabla

[WHERE condición]
Es más sencilla que las anteriores, elimina los registros de la tabla que cumplan la condición indicada.
Instrucciones de control de transacciones (DTL)
Commit
La instrucción COMMIT hace que los cambios realizados por la transacción sean definitivos, irrevocables.
Rollback
Esta instrucción regresa a la instrucción anterior al inicio de la transacción, normalmente el último COMMIT.
Consultas de datos con SQL - DQL

DQL es la abreviatura del Data Query Language (lenguaje de consulta de datos) de SQL. El único comando que
pertenece a este lenguaje es el versátil comando SELECT
Este comando permite:
• Obtener datos de ciertas columnas de una tabla (proyección)

• Obtener registros (filas) de una tabla de acuerdo con ciertos criterios (selección)
• Mezclar datos de tablas diferentes (asociación, join)
• Realizar cálculos sobre los datos
• Agrupar datos
Sintaxis:
SELECT * | {[DISTINCT] columna | expresión [[AS] alias], ...}
FROM tabla;
Cálculo
Los operadores + (suma), - (resta), * (multiplicación) y / (división), se pueden utilizar para hacer cálculos en las
consultas. Cuando se utilizan como expresión en una consulta SELECT, no modifican los datos originales sino que
como resultado de la vista generada
por SELECT, aparece un nueva columna.
Condiciones
Se pueden realizar consultas que restrinjan los datos de salida de las tablas. Para ello se utiliza la cláusula WHERE.
Esta cláusula permite colocar una condición que han de cumplir todos los registros, los que no la cumplan no
aparecen en el resultado.
Between
El operador BETWEEN nos permite obtener datos que se encuentren en un rango.
In
Permite obtener registros cuyos valores estén en una lista de valores.
142
Base de Datos
Like
Se usa sobre todo con textos, permite obtener registros cuyo valor en un campo cumpla una condición textual.
LIKE utiliza una cadena que puede contener los símbolos % -:
Is null
Devuelve verdadero si el valor que examina es nulo.
Agrupaciones
Es muy común utilizar consultas en las que se desee agrupar los datos a fin de realizar cálculos en vertical, es decir
calculados a partir de datos de distintos registros. Para ello se utiliza la cláusula GROUP BY que permite indicar en
base a qué registros se realiza la agrupación.
Cláusula Having
A veces se desea restringir el resultado de una expresión agrupada, para ello utilizamos la cláusula having.
Autoevaluación
1. ¿Con que clausula busco los campos de una tabla cuando sean nulos?
2. ¿Con que clausula puedo realizar agrupaciones de campos?
3. ¿Cuál es el operador permite obtener datos que se encuentren en un rango?
4. ¿Cómo puedo buscar datos que se encuentran en una lista?
5. ¿Cómo se anula definitivamente los cambios, de una transacción?
6. ¿Qué hace un COMMIT?
7. ¿Cómo puedo restringir el resultado de una expresión agrupada?
8. ¿Qué utilizaría sintaxis utilizaría para mostrar ventas por regiones de la tabla ventas (región, sucursal, vendedor,
factura, importe)?
Investigación
1. Visite: http://msdn.microsoft.com/en-us/library/aa258243(v=sql.80).aspx
2. Visite: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/commit_statement.htm
3. Visite http://dev.mysql.com/doc/refman/5.0/en/commit.html
4. Busque en los mismos sitios para rollback.
143
Tema Nº 15
Ejemplos de lo aprendido
En los siguientes ejemplos veremos, el uso del SELECT, la creación de campos calculados, el uso de operadores
de funciones agregadas y de group by.
1. Mostrar las lista de las oficinas de ventas con sus objetivos y ventas reales.
SELECT CIUDAD, OBJETIVO, VENTAS
FROM Oficinas
GO
2. Mostrar los nombres, oficinas y fechas de contrato de los vendedores

SELECT NOMBRE, OBJETIVO, VENTAS
FROM REPVENTAS
GO
3. Mostrar el nombre, cuota y ventas del empleado de código 107

SELECT NOMBRE, CUOTA, VENTAS
FROM REPVENTAS
WHERE NUM_EMPL = 107
GO
Nótese que en esta última consulta se ha empleado la cláusula WHERE para restringir el número de filas a devol-
ver, a diferencia de la primera que le devolvía todas las filas.
4. Mostrar el monto de ventas promedio de los vendedores

SELECT AVG(VENTAS)
FROM REPVENTAS
GO
En este último ejemplo se obtiene un único valor que representa una pequeña tabla, aunque conste de una sola
fila y una sola columna. Este valor es el resultado de sumar todos los valores del campo VENTAS y dividirlo entre
el número de filas.
5. Mostrar los nombres y fechas de contratos de los vendedores que superaron la barrera de los 500,000
SELECT NOMBRE, CONTRATO
FROM REPVENTAS
WHERE VENTAS>500000
GO
En este último ejemplo no se obtienen filas, con lo cual queda demostrado que no siempre las consultas deben
devolver filas, esto representa que ningún registro cumplió con la condición expresada en la cláusula WHERE.
6. Mostrar la CIUDAD, REGION y el IMPORTE de por encima o por debajo del OBJETIVO
SELECT CIUDAD, REGION, (VENTAS - OBJETIVO) As SITUACION FROM OFICINAS
GO
Nótese que en el ejemplo se emplea la cláusula As que permite asignar un encabezado de columna al campo
calculado (VENTAS – OBJETIVO).
De los resultados podemos observar que las ciudades de Chicago y Denver aun se encuentran por debajo del
objetivo, mientras que las demás oficinas ya superaron el objetivo.
144
Base de Datos
7.Mostrar el valor del inventario para cada producto

Select Id_Fab, Id_Producto, Descripcion, (Existencias*Precio) As Valor
From Productos
GO
Similar al ejemplo anterior se emplea un campo calculado al cual se le asigna un encabezado a través del empleo
de la cláusula As.
8. Muestra que sucedería si se eleva el monto de la cuota decada vendedor en un 3% de sus ventas anuales
SELECT NOMBRE, CUOTA, (CUOTA*1.03) As CUOTAPROYECTADA
FROM REPVENTAS
GO
9. Mostrar el nombre, mes y año de contrato de cada representante de ventas

Select Nombre, Month(Contrato) As Mes, Year(Contrato) As Año
FROM REPVENTAS
GO
10. Mostrar los campos CIUDAD y VENTAS separados por la cadena ‘ tiene ventas de ‘
SELECT CIUDAD, ‘ tiene ventas de ‘ , VENTAS
FROM OFICINAS
GO
11. Mostrar todos los campos de la tabla CLIENTES

SELECT * FROM CLIENTES
GO
El caracter * permite recuperar todos los campo y todas las filas de la tabla que se está consultando.
12. Mostrar todos los campos de la tabla OFICINAS, asi como también una columna que indique si se alcanzo o
no el objetivo.
SELECT *, (VENTAS - OBJETIVO) as SITUACION
FROM OFICINAS
GO
13. Mostrar las oficinas que han superado el OBJETIVO trazado:

SELECT CIUDAD, VENTAS, OBJETIVO
FROM OFICINAS
WHERE VENTAS > OBJETIVO
GO
14. Mostrar los vendedores que están dirigidos por Jorge Castro (código 104)
SELECT NOMBRE, VENTAS
FROM REPVENTAS
WHERE DIRECTOR = 104
GO
15. Muestre a los vendedores contratados antes de 1988

SELECT NOMBRE
FROM REPVENTAS
WHERE CONTRATO < ’01-01-88’
GO
145
16. Mostrar las oficinas que están por debajo del 80% del objetivo
SELECT CIUDAD, VENTAS, OBJETIVO
FROM OFICINAS
WHERE VENTAS < (0.8 * OBJETIVO)
GO
17. Mostrar las oficinas que no están a cargo de dir 108

SELECT CIUDAD, DIR
FROM OFICINAS
WHERE DIR <> 108
GO
18. Mostrar a los vendedores que superaron sus cuotas

SELECT NOMBRE
FROM REPVENTAS
WHERE VENTAS > CUOTA
GO
19. Mostrar los clientes que tiene un límite de crédito entre 45000 y 60000
SELECT EMPRESA, LIMITE_CREDITO FROM CLIENTES
WHERE LIMITE_CREDITO BETWEEN 45000 AND 60000
GO
20. Mostrar a los vendedores que trabajan en New York, Denver, o Atlanta
SELECT NOMBRE, CUOTA, VENTAS FROM REPVENTAS
WHERE OFICINA_REP IN (11, 13, 22)
GO
21. Mostrar a los clientes cuya razón social comienza con S

SELECT EMPRESA, LIMITE_CREDITO
FROM CLIENTES
WHERE EMPRESA LIKE ‘S%’
GO
22. Mostrar a los clientes cuya razón social incluye una Y en su nombre
SELECT EMPRESA, LIMITE_CREDITO
FROM CLIENTES
WHERE EMPRESA LIKE ‘%Y%’
GO
23. Mostrar los vendedores que no tiene asignada una oficina

SELECT NOMBRE
FROM REPVENTAS
WHERE OFICINA_REP IS NULL
GO
24. Mostrar los vendedores que tienen asignada una oficina

SELECT NOMBRE
FROM REPVENTAS
WHERE OFICINA_REP IS NOT NULL
GO
146
Base de Datos
25. Mostrar a los vendedores que tienen ventas por debajo de sus cuotas o ventas menores a 300000
FROM REPVENTAS
WHERE VENTAS < CUOTA
OR VENTAS < 300000
GO
26. Mostrar a los vendedores que tienen ventas por debajo de sus cuotas y ventas menores a 300000
FROM REPVENTAS
WHERE VENTAS < CUOTA
AND VENTAS < 300000
GO
27. Mostrar la información de las oficinas ordenadas por Región

SELECT *
FROM OFICINAS
ORDER BY REGION
GO
28. Mostrar las oficinas ordenadas por las ventas en forma descendente:
SELECT CIUDAD, REGION, VENTAS
FROM OFICINAS
ORDER BY VENTAS DESC
GO
29. Mostrar las oficinas organizadas en forma descendente por el rendimiento de ventas.
SELECT CIUDAD, REGION, (VENTAS-OBJETIVO) AS RENDIMIENTO
FROM OFICINAS
ORDER BY 3 DESC
GO
30. Mostrar las oficinas organizadas por REGION y dentro de cada región por el rendimiento de las VENTAS en
forma descendente.
SELECT CIUDAD, REGION, (VENTAS-OBJETIVO) AS RENDIMIENTO
FROM OFICINAS
ORDER BY REGION, 3 DESC
GO
31. Indicar la cuota promedio y las ventas promedio de los vendedores

SELECT AVG(CUOTA), AVG(VENTAS)
FROM REPVENTAS
GO
Nótese que la función AVG primero suma todos los valores de la columna especificada en el argumento y luego
divide este total entre el número de filas.
32. Mostrar la suma total de las cuotas y de las ventas de todos los vendedores
SELECT SUM(CUOTA), SUM(VENTAS)
FROM REPVENTAS
GO
Nótese que la función SUM suma todos los valores de la columna especificada en el argumento.
147
33. Mostrar el importe promedio del cliente de código 103

SELECT AVG(IMPORTE)
FROM PEDIDOS
WHERE CLIE = 2103
GO
34. Mostrar el mayor y menor monto de cuotas

SELECT MIN(CUOTA), MAX(CUOTA)
FROM REPVENTAS
GO
35. Mostrar el número de clientes que existen.

SELECT COUNT(EMPRESA)
FROM CLIENTES
GO
36.Mostrar cuantos pedidos superaron el importe de los 25000

SELECT COUNT(IMPORTE)
FROM PEDIDOS
WHERE IMPORTE > 25000
GO
37. Mostrar cual es el promedio de pedidos por cada vendedor

SELECT REP, AVG(IMPORTE)
FROM PEDIDOS
GROUP BY REP
GO
38. Mostrar el rango de cuotas asignadas en cada oficina

SELECT OFICINA_REP, MIN(CUOTA), MAX(CUOTA)
FROM REPVENTAS
GROUP BY OFICINA_REP
GO
39. Mostrar el número de vendedores asignados a cada oficina

SELECT OFICINA_REP, COUNT(*)
FROM REPVENTAS
GROUP BY OFICINA_REP
GO
40. Mostrar los valores totales por cada cliente y por cada vendedor
SELECT REP, CLIE, SUM(IMPORTE)
FROM PEDIDOS
GROUP BY REP, CLIE
ORDER BY REP
GO
148
Base de Datos
41. Mostrar un informe que calcule el total de importes por cada cliente, vendedor, ordenados por vendedor y
luego por cliente.
SELECT REP, CLIE, IMPORTE
FROM PEDIDOS
ORDER BY REP, CLIE
COMPUTE SUM(IMPORTE) BY REP, CLIE
COMPUTE SUM(IMPORTE) , AVG(IMPORTE) BY REP
Para poder emplear la cláusula COMPUTE debe ordenar primero la información.
42. Mostrar los promedios de ventas que superan los 30000

SELECT REP, AVG(IMPORTE)
FROM PEDIDOS
GROUP BY REP
HAVING SUM(IMPORTE) > 30000
GO
Select anidados.
43. Listar los datos de los autores

select * from autor
44. Listar nombre y edad de los estudiantes

select nombre,edad
from estudiante
45. ¿Qué estudiantes pertenecen a la carrera de Informática?

select nombre
from estudiante
where carrera=”Informatica”
46. Listar los nombres de los estudiantes cuyo apellido comience con la letra G?
SELECT nombre
FROM estudiante
WHERE nombre LIKE “* G*”
149
47. ¿Quiénes son los autores del libro “Visual Studio Net”, listar solamente los nombres?
SELECT nombre
FROM autor
WHERE idautor IN
(
SELECT idautor
FROM libaut
WHERE idlibro IN
(
SELECT idlibro
FROM libro
WHERE titulo=’Visual Studio Net’
)
)
48. ¿Qué autores son de nacionalidad USA o Francia?

SELECT *
FROM autor
WHERE nacionalidad IN(‘USA’,’Francia’)
49. ¿Qué libros No Son del Area de Internet?

SELECT *
FROM libro
WHERE area <> ‘Internet’
50. ¿Qué libros se prestó el Lector “Raul Valdez Alanes”?

SELECT *
FROM libro
WHERE idlibro IN
(
SELECT idlibro
FROM prestamo
WHERE idlector IN
(
SELECT idlector
FROM estudiante
WHERE nombre=’Raul Valdez Alanes’
)
)
51. Listar el nombre del estudiante de menor edad

SELECT nombre
FROM estudiante
WHERE edad IN
(
SELECT min(edad)
FROM estudiante
)
150
Base de Datos
52. Listar los nombres de los estudiantes que se prestaron Libros de Base de Datos
}
SELECT *
FROM estudiante
WHERE idlector IN
(
SELECT idlector
FROM prestamo
WHERE idlibro IN
(
SELECT idlibro
FROM libro
WHERE area=’Base de Datos’
)
)
53. Listar los libros de editorial AlfayOmega

SELECT *
FROM libro
WHERE editorial =’AlfaOmega’
54. Listar los libros que pertenecen al autor Mario Benedetti

SELECT *
FROM libro
WHERE idlibro IN
(
SELECT idlibro
FROM libaut
WHERE idautor IN
(
SELECT idautor
FROM autor
WHERE nombre=’Benedetti Mario’
)
)
55. Listar los títulos de los libros que debían devolverse el 10/04/07
SELECT *
FROM libro
WHERE idlibro IN
(
SELECT idlibro
FROM prestamo
WHERE fechadevolucion=’04/10/07’
AND devuelto=’No’
)
56. Hallar la suma de las edades de los estudiantes

SELECT sum(edad) AS [La suma de las edades es: ]
FROM estudiante
151
57. Listar los datos de los estudiantes cuya edad es mayor al promedio
SELECT *
FROM estudiante
WHERE edad >
(
SELECT avg(edad)
FROM estudiante
)
Ejercitación
De las tablas:
CLIENTE(codigo,nombre,domicilio,provincia)
PRODUCTO(codigo_producto,nombre_producto)
ITEM_VENTAS(número_factura,codigo_producto,cantidad,precio)
VENTAS(numero_factura,codigo_cliente,fecha)
Responder con la sintaxis correcta
1. Obtener el nombre y el domicilio de los clientes que viven en la provincia de Misiones.

2. Obtener el nombre, domicilio y provincia de los clientes que viven en la provincia de Misiones o de Rio Negro.
3. Obtener el importe total en pesos por factura y producto, especificando el numero de factura, el código del
producto y el importe total.
4. Sobre la consulta 3, obtener solo el importe total para el producto a.
5. Sobre la consulta 3, obtener solo el importe total para las facturas mayores iguales a 2 y menores iguales a 5
y solo para el producto código c.
6. Sobre la consulta 3, obtener solo el importe total para los registros cuyo importe total sea mayor a 200.
7. Obtener un listado de las facturas realizadas especificando número de factura, nombre del producto y canti-
dad vendida.
8. Obtener un listado de las facturas realizadas cuya cantidad sea mayor igual a 15 especificando numero de
factura, nombre del producto y cantidad vendida.
9. Obtener un listado de las facturas realizadas indicando número de factura, nombre del cliente, nombre del
producto, cantidad y precio y el importe total.
10. Obtener la cantidad de unidades máxima.
11. Obtener la cantidad total de unidades vendidas del producto c.
12. Cantidad de unidades vendidas por producto, indicando la descripción del producto, ordenado de mayor a
menor por las cantidades vendidas.
13. Cantidad de unidades vendidas por producto, indicando la descripción del producto, ordenado alfabética-
mente por nombre de producto para los productos que vendieron más de 30 unidades.
14. Obtener cuantas compras (1 factura = 1 compra) realizo cada cliente indicando el código y nombre del cliente
ordenado de mayor a menor.
15. Promedio de unidades vendidas por producto, indicando el código del producto para el cliente 1.
16. Cantidad de unidades vendidas por cliente y producto, indicando el nombre del cliente, la descripción del
producto para los productos que vendieron entre 15 y 35 unidades.
Investigación
1. Investigue como se harían las mismas consultas en Oracle o MySQL.
2. Visite: http://msdn.microsoft.com/en-us/sqlserver/bb671432
152
Base de Datos
Tema Nº 16
Introducción a SQL Server 2000
SQL Server 2000 es un sistema de gestión de bases de datos relacionales (SGDBR o RDBMS: Relational Database
Management System) diseñado para trabajar con grandes cantidades de información y la capacidad de cumplir
con los requerimientos de proceso de información para aplicaciones comerciales y sitios Web.
SQL Server 2000 ofrece el soporte de información para las tradicionales aplicaciones Cliente/Servidor, las cuales
están conformadas por una interfaz a través de la cual los clientes acceden a los datos por medio de una LAN.
La hoy emergente plataforma NET exige un gran porcentaje de distribución de recursos, desconexión a los servi-
dores de datos y un entorno descentralizado, para ello sus clientes deben ser livianos, tales como los navegadores
de Internet los cuales accederán
a los datos por medio de servicios como el Internet Information Services(IIS).
SQL Server 2000 está diseñado para trabajar con dos tipos de bases de datos :
• OLTP (OnLine Transaction Processing) Son bases de datos caracterizadas por mantener una gran cantidad
de usuarios conectados concurrentemente realizando ingreso y/o modificación de datos. Por ejemplo:
entrada de pedidos en línea, inventario, contabilidad o facturación.
• OLAP (OnLine Analytical Processing) Son bases de datos que almacenan grandes cantidades de datos que
sirven para la toma de decisiones, como por ejemplo las aplicaciones de análisis de ventas.
SQL Server puede ejecutarse sobre redes basadas en Windows Server así como sistema de base de datos de es-
critorio en máquinas Windows NT Workstation, Windows Millenium y Windows 98.
Los entornos Cliente/Servidor, están implementados de tal forma que la información se guarde de forma cen-
tralizada en un computador central (servidor), siendo el servidor responsable del mantenimiento de la relación
entre los datos, asegurarse del correcto almacenamiento de los datos, establecer restricciones que controlen la
integridad de datos, etc.
Del lado cliente, este corre típicamente en distintas computadoras las cuales acceden al servidor a través de una
aplicación, para realizar la solicitud de datos los clientes emplean el Structured Query Language (SQL), este len-
guaje tiene un conjunto de
comandos que permiten especificar la información que se desea recuperar o modificar.
Existen muchas formas de organizar la información pero una de las formas más efectivas de hacerlo está repre-
sentada por las bases de datos relacionales, las cuales están basadas en la aplicación de la teoría matemática de
los conjuntos al problema de la organización de los datos. En una base de datos relacional, los datos están orga-
nizados en tablas (llamadas relaciones en la teoría relacional).
Una tabla representa una clase de objeto que tiene importancia para una organización.
Por ejemplo, se puede tener una base de datos con una tabla para empleados, otra para clientes y otra para pro-
ductos del almacén. Las tablas están compuestas de columnas y filas (atributos y tuplas en la teoría relacional).
La tabla Empleados tendría columnas para el nombre, el apellido, código del empleado, departamento, categoría
laboral y cargo. Cada fila representa una instancia del objeto representado por la tabla. Por ejemplo, una fila de la
tabla Empleados representa el empleado cuyo Id. de empleado es 12345.
Al organizar los datos en tablas, se pueden encontrar varias formas de definirlas. La teoría de las bases de datos
relacionales define un proceso, la normalización, que asegura que el conjunto de tablas definido organizará los
datos de manera eficaz.
153
Pasos para la instalación de SQL server sobre Windows NT Server

Coloque el CD de instalación
Aparecerá la siguiente pantalla
Después se presentará la siguiente pantalla:
A continuación aparecerá una ventana que da la bienvenida al proceso de instalación, pulse Siguiente (Siguiente)
en la siguiente pantalla:
154
Base de Datos
A continuación aparece una pantalla que le solicitará elegir entre una instalación local o una instalación remota,
pulse Siguiente (Siguiente) en la siguiente pantalla:
Si es la primera vez que instala SQL Server 2000 aparecerá la siguiente pantalla:
155
Ingrese la información del usuario y pulse Siguiente (Siguiente).
Acepte las condiciones del licenciamiento:
156
Base de Datos
Luego de aceptar las condiciones del licenciamiento aparecerá una caja de diálogo solicitándole que seleccione
uno de los tipos de instalación, para ello tendrá las siguientes opciones:
Sólo Herramientas Cliente (Client Tools only), cuando requiera instalar herramientas clientes para administrar un
servidor SQL Server existente, así como también los componentes de conectividad los libros en línea y opcional-
mente los ejemplos.
Servidor y Herramientas Cliente (Server and Client Tools), selecciona esta opción cuando requieras instalar un
servidor SQL Server 2000, el cual deba contar con todas las herramientas.
Sólo Conectividad (Connectivity Only), seleccione esta opción para instalar las librerías de conectividad para los clientes.
Para cualquiera de las tres opciones se instalará previamente MDAC 2.6, para la instalación que estamos realizan-
do seleccione Servidor y Herramientas Cliente (Server and Client Tools) y luego pulse Siguiente (Siguiente):
A continuación aparecerá una caja de diálogo donde especificará el nombre de la instancia que está instalando,
si es la primera vez En forma predeterminada tomará el nombre del equipo donde se encuentra instalando:
157
Luego de pulsar Siguiente (Siguiente), tendrá la posibilidad de seleccionar el tipo de instalación a ejecutar, se-
leccione Personalizada (Custom) para que pueda observar las diferentes opciones que configura el instalador, en
esta primera pantalla se muestran los espacios requeridos así como también las carpetas donde se almacenaran
las diferentes librerías de SQL Server:
Luego de pulsar Siguiente (Siguiente) aparecerá una lista que le permitirá seleccionar los componentes a instalar,
desplazar la lista Componentes (Components) y activar las casillas Ejemplos de Código (Code Simples):
158
Base de Datos
Inmediatamente se le solicitará una cuenta para los servicios, si se encuentra trabajando en un entorno de red,
asigne una cuenta de un usuario que pertenezca al grupo Administradores (Administrators) del Dominio:
Seleccione el modo de autentificación para acceder a SQL Server 2000:
159
A continuación podrá determinar el conjunto de caracteres con los cuales trabajará, asimismo podrá determinar
si las consultas distinguirán o no las mayúsculas de las minúsculas.
Activar las librerías de red de acuerdo a los usuarios que tendrá su origen de datos:
160
Base de Datos
Luego de pulsar Siguiente (Siguiente) aparecerá una pantalla indicándole que se ha completado el trabajo de
recolección de información, pulse Siguiente (Siguiente) para iniciar el copiado de archivos:
Al completar la instalación se muestra la siguiente pantalla, pulse Finalizar (Finish) para finalizar:
161
Verificar la instalación de SQL Server
Una vez finalizada la instalación debe revisar la instalación para cerciorarse que el producto se ha instalado co-
rrectamente para ello puede mostrar el Administrador de Servicios (Service Manager) que le permitirá mostrar el
estado de los servicios, este utilitario tiene el siguiente aspecto:
Seguidamente observará una caja de diálogo con el siguiente aspecto:
Otra de las formas de verificar el estado de la instalación es haciendo pruebas con las sentencias a nivel del sím-
bolo del sistema que ofrece SQL Server como es el caso del utilitario OSQL, para comprobar su funcionamiento
abra una ventana del sistema y digite el siguiente comando:
C:\>osql –S<Susuariovidor> -U<usuario> –P<contraseña> –q “Select CategoryName From Northwind..Catego-

ries” <pulse Enter>
Reemplace el texto en negrita por los valores adecuados.
162
Base de Datos
El resultado será:
Otra manera de poder verificar la instalación de SQL Server es revisar los servicios que se cargan, para ello presio-
ne el botón del menú Inicio (Start), seleccione Programas (Programs), Herramientas Administrativas (Administra-
tive Tools) y haga clic en ServiciosServices):
Compruebe que los siguientes servicios se encuentren iniciados:
• MSSQL Server Este servicio es el motor de base de datos, este es el componente que procesa todas las senten-
cias del Transact-SQL y administra todos los archivos que comprometen las bases de datos del servidor, entre
sus principales funciones podemos mencionar:
1. La asignación de recursos del servidor entre múltiples usuarios concurrentes.
2. Previene los problemas lógicos, como por ejemplo prevenir que los usuarios modifiquen la misma infor-
mación al mismo tiempo.
3. Asegura la consistencia e integridad de datos.
163
• SQL Server Agent Este servicio trabaja junto al MSSQL Server para crear y administrar Alertas, Tareas (locales o
multiserver) y Operadores. Entre sus principales funciones podemos mencionar:
1. Las alertas proveen información acerca del estado de un proceso, como por ejemplo indicar cuando finali-
zo una tarea con éxito o fracaso.
2. Este servicio incluye un motor que permite crear tareas y programarlos para que se ejecuten automática-
mente.
3. Puede enviar correos electrónicos, puede indicar la ejecución de una tarea cuando una alerta ocurre.
• MS DTC Permite incluir múltiples orígenes de datos en una transacción, se encarga de coordinar y asegurar que
las actualizaciones sobre todos los servidores sean permanentes, y si en caso estos cambios causaran un error
deshacer todos.
• Microsoft Search Este es un servicio opcional y se encarga de realizar búsquedas sobre información tipo carác-
ter creando índices para facilitar estas consultas.
Además de ello podrá ingresar a la consola de administración de SQL Server denominada Administrador Corpo-
rativo (Administrador Empresarial), para ello siga la siguiente secuencia:
A continuación tendrá la interfaz del Administrador Corporativo (Administrador Empresarial), tal como lo mues-
tra la siguiente representación:
164
Base de Datos
Modos de autenticar las cuentas de los usuarios

SQL Server valida a los usuarios en dos niveles de seguridad: una a través de un Inicio de sesión que establece el
hecho de realizar la conexión a SQL Server y otro a partir de la validación de los permisos que tienen los usuarios
sobre una base de datos.
Inicio de sesión
Todos los usuarios deben tener un Inicio de sesión para poder conectarse a SQL Server, para esto SQL Server re-
conoce 2 mecanismos de autentificación:
SQL Server es cuando el usuario debe proveer de un usuario y una contraseña que serán validados por el propio
SQL Server cuando el cliente intente conectarse.
Windows NT es cuando una cuenta o grupo de Windows NT controla el acceso a SQL Server, el cliente no provee
usuario y contraseña, ya que se empleará la cuenta con la que se ingresa al sistema operativo.
Para modificar la autenticación realice los siguientes pasos:

Haga clic derecho sobre el servidor, en el menú contextual haga clic sobre la opción Properties.
165
En la caja de diálogo haga clic sobre la ficha Seguridad, se presentará la siguiente pantalla:
Seleccione la opción “SQL Server y Windows” cuando desee brindar servicios de información a terceros por ejem-
plo a usuarios de internet. Seleccione “Sólo Windows” cuando los datos estarán disponibles sólo a los empleados
de la organización. En cualquiera de los dos casos debe pulsar Aceptar, espere por un instante mientras SQL Ser-
ver 2000 detiene los servicios y los vuelve a iniciar para hacer efectivos los cambios.
Hecho esto Ud. podrá definir sus Inicios de sesión de acceso a SQL Server, para ello realice la siguiente secuencia
desde el Administrador Empresarial:
Expanda la carpeta Seguridad del Administrador Empresarial y haga clic derecho sobre Inicios de sesión
166
Base de Datos
Aparecerá la siguiente caja de diálogo:

En la ficha Acceso a base de datos podrá especificar que el Inicio de sesión se definirá como usuario de alguna de
las bases de datos existentes. Pulse Aceptar al finalizar.
167
La creación de Inicios de sesión también es posible desde el Analizador de Consultas, que es una herramienta a
la cual accesamos a partir de la siguiente secuencia:
Observará el siguiente entorno:
Usuarios de Base de Datos

Una de las tareas comunes al administrar SQL Server es permitir el acceso a bases de datos y la asignación de
permisos o restricciones sobre los objetos que conforman una base de datos.
SQL Server 2000 permite trabajar a nivel de Roles y Usuarios.
Un rol es un conjunto de derechos asignados, los cuales se convierten en una gran alternativa para agrupar un
conjunto de permisos, de tal forma que cuando se incorpore un nuevo usuario a la base de datos, ya no se le tie-
ne que dar permiso por permiso por cada uno de los objetos que requiera emplear, sino mas bien su cuenta de
usuario es agregada al rol, y si al rol tiene que asignársele acceso sobre un nuevo elemento automáticamente el
permiso o la restricción afectará a los usuarios que pertenezcan a un rol.
Los usuarios representan los usuarios que tienen acceso a la base de datos y están mapeados a un Inicio de se-
sión, aunque pueden tener diferente identificador, por ejemplo el Inicio de sesión puede tener como nombre
Jcabrera pero al definir un Usuario podemos usar Jorge.
168
Base de Datos
Después de que se crearon los Inicios de sesión para conectarse a SQL Server, se deben definir los accesos a las
bases de datos requeridas, para ello es necesario definir Usuarios en cada BD, estos usuarios permitirán controlar
el acceso a los distintos objetos incluyendo los datos que estos contienen.
Para ello realice el siguiente proceso:

Expanda la base de datos donde desea definir al nuevo usuario y haga clic derecho sobre la carpeta Usuarios

Seleccione un Inicio de sesión de la lista y pulse Aceptar.
También es posible realizar esta tarea desde el Analizador de Consultas para ello emplee la siguiente secuencia
de instrucciones:
Use Northwind
GO
Sp_GrantDBAccess ‘Usuario01’
GO
169
Además de los Inicios de sesión y usuarios SQL Server brinda un conjunto de roles por servidor y por base de
datos que son derechos predefinidos que podrán especificarse por cada usuario de ser necesario. También es
posible crear roles personalizados.
Los roles son los siguientes:
Investigación
1. Visite la página de Microfoft – SQL server.
2. Visite http://download.oracle.com/docs/html/B10131_02/install.htm
3. Visite http://dev.mysql.com/doc/refman/5.1/en/installing.html
Bibliografía
Introducción a la informática – Mario D Albarracín, Eduardo A Lancharro, Miguel García López.Mc Graw Hill.
Organización de base de datos – James Martin. Prentice Hall.
Diseño de sistemas de Información - Burch J.G., Grudnistki G. Ed. Megabyte
Concepción y diseño de base datos del Modelo E/R al Modelo Relacional - Adoración de Miguel, Mario Piattini. Ra-ma
Sistemas de base de datos – conceptos fundamentales – Elmasri - Navathe. Pearson educación.
Sistemas de base de datos – C.J. Date – Addison-Wesley Iberoamericana.
Diseño de base de datos Problemas resueltos - Adoración de Miguel, Paloma Martinez, Elena Castro, Dolores Cua-
dra, Ana Iglesias, Carlos Nieto. Ra-ma.
170
Base de Datos

171
Corrección autoevaluación tema 1
1. Defina sistemas de información SI.

Sistema de información’ (SI) es un conjunto de elementos orientados al tratamiento y administración de datos
e información, organizados y listos para su posterior uso, generados para cubrir una necesidad (objetivo).
2. En un pago con tarjeta de crédito que componentes de un SI intervienen.

Los componentes son tres entrada, procesamiento y salida.
Entrada al pasar la tarjeta por el POSTNET (Postal Numeric Encoding Technique) ingreso datos, el procesamien-
to del cobro y salida es el Ticket.
3. La agenda de su teléfono celular con que componente de SI se pude identificar análogamente.

El componente es el de almacenamiento.
Dicho componente es el lugar donde se contienen los datos necesarios para atender las necesidades de todos
los usuarios. Este componente lo consideraremos desde dos puntos de vista uno físico y otro lógico.
Físico: compuesto por los medios de almacenamiento.
Lógico: se refiere a la manera que se relacionan los datos entre si.
4. ¿Por qué cree que es de suma importancia la calidad de una salida o resultado de un proceso?
El resultado o saluda se basa principalmente en su calidad. Cuando hablamos de calidad nos referimos especí-
ficamente a tres requisitos que debe cumplir dicha salida: exactitud, oportunidad y relevancia.
• Exactitud: el resultado no debe tener desvíos.

• Oportunidad: el resultado debe estar disponible cuando el usuario lo necesite.
• Relevancia: el resultado tiene que ser de importancia para en usuario.
5. Si estoy pasando una carpeta con música en mi mp3 y me aparece un cartel que no tengo espacio. ¿Qué reque-
rimiento esta no se está cumpliendo en ese proceso de copiado?
El requerimiento es el de volumen, este último se refiere a la cantidad de datos que deben procesarse en un
periodo dado.
6. Me conecto a Internet y quiero leer un diario online, abro el navegador pongo la dirección de la pagina pero no
carga las imágenes y al rato aparece una leyenda que dice expiró el tiempo de conexión con el servidor. ¿Qué
requerimiento esta no se está cumpliendo en ese proceso de cargar la web?
El requerimiento es la restricción de tiempo, entendemos por esto periodo de tiempo permitido o aceptable
entre el momento que se requieren los datos y el sistema los tiene disponible.
7. ¿Qué entiende por demanda computacional? Conceptualice sus componentes.

Demandas computacionales: es la combinación de volumen, complejidad y restricción de tiempo.
• Volumen: cantidad de datos que deben procesarse en un periodo dado.

• Complejidad: cantidad de operaciones y tamaño de las mismas entre datos.
• Restricciones de tiempo: periodo de tiempo permitido o aceptable entre el momento que se requieren los
datos y el sistema los tiene disponible.
8. Le piden que arme un sistema de stock, analiza algunos aspectos como que el sistema se pueda armar, que
existan los instrumentos para llevarlo a cabo, es decir el hardware que pueda soportar dicho sistema. Revisa
que lo que se le esta pidiendo no infrinja la ley, que se licencien las aplicaciones que así lo requieran. Se asegura
que volumen de datos se van almacenar para poder dimensionar la compra de los discos rígidos. ¿Qué se está
analizando?
Se está analizando la factibilidad técnica. Legal y operacional.
172
Base de Datos
1. ¿Para qué sirve una base de datos en una organización?

Una base de datos puede definirse como una colección de datos (objetos) interrelacionados almacenados en
conjunto sin redundancias perjudiciales o innecesarias; su finalidad es la de servir a una aplicación o más, de
la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que
los usan; se emplean métodos bien determinados para incluir datos nuevos y para modificar o extraer los datos
almacenados.
2. ¿A qué se refiere la independencia lógica y física de los datos?

Independencia física de los datos se refiere a el hardware de almacenamiento y las técnicas físicas de almace-
namiento podrán ser modificados sin obligar a la modificación de los programas de aplicación.
Mientras que independencia lógica de los datos alude a que pueden agregarse nuevos ítems de datos, o ex-
pandirse la estructura lógica general, sin que sea necesario reescribir los programas de aplicación existentes,
solo se modificara la aplicación que los utiliza.
3. El control centralizado de los datos es una de las características de la base de datos. ¿Cuales otras características
son posibles gracias al control centralizado?
Integridad de daros es garantizar que los datos de la base de datos sean exactos. El control centralizado de la
base de datos ayuda a evitar la inconsistencia de los datos, por el mismo hecho de encontrarse en un solo lugar
y mediante medidas de seguridad, restricciones y controles para evitar inconsistencias.
4. Analicemos esta situación: Tengo mi curriculum que lo hice hace un tiempo en office 2003 después de unos
años cambio el office por el 2007, puedo decir que cambio de aplicación, mientras que mi curriculum es el dato
sigue siendo el mismo. Si hacemos una analogía de esta situación con una base de datos. ¿Que característica
de las bases de datos se pone en manifiesto?
Independencias de los datos y las aplicaciones.

Se refiere a que podemos quitar un programa que se conecta a la base y cambiarlo por otro sin tener que
modificar la base. Lo mismo a la inversa podemos cambiar la base de datos y debería ser transparente para los
programas que se conectan a ella.
5. De los componentes de la base de datos, los usuarios ¿en función de que se clasifican?
Los usuarios se clasifican según experiencia e intelección con la base de datos.
6. ¿En qué se diferencia una base de datos jerárquica y una de red?

Un modelo de red es ligeramente distinto del jerárquico; su diferencia fundamental es la modificación del
concepto de nodo: se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo
jerárquico).
7. ¿En qué se diferencia una base de datos relacional y una multidimencional?

El modelo de datos más extendido es el modelo relacional, este modelo se basa en las leyes de la normalización
de bases de datos; según estás normas, y concretamente, según la primera forma normal, un campo de una
base de datos no puede contener valores múltiples. En una base de datos multivaluada no se aplica la regla de
la primera forma normal, es decir, se permite que un campo pueda tener más de un valor almacenado.
8. ¿Para qué me sirve una base de datos orientada a objetos?

En una base de datos orientada a objetos, la información se representa mediante objetos como los presentes
en la programación orientada a objetos.
Las bases de datos orientadas a objetos se diseñan para trabajar bien en conjunción con lenguajes de progra-
mación orientados a objetos. Dichos objetos se extienden en los lenguajes como datos persistentes de forma
transparente, control de concurrencia, recuperación de datos, consultas asociativas y otras capacidades.
173
1. ¿Qué propuso ANSI-SPARC?

En 1975 ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Commit-
tee) propone una arquitectura de sistemas de bases de datos de tres esquemas o niveles de abstracción como
ayuda para conseguir la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas
por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos.
2. ¿Cuál es la finalidad?
Conseguir la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte
de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos.
3. ¿Qué entiende por Nivel interno?

Esquema físico o nivel interno es la representación inferior de una Base de Datos, por ello es el más cercano al
almacenamiento físico.
Permite describir los datos tal como están almacenados en la computadora; por ejemplo:
Los archivos que los contienen (nombre, organización, ubicación...).
Los registros de estos archivos (longitud, campos...).
Las rutas de acceso a esos registros (índices, encadenamientos, archivos invertidos...)
Este es el nivel más bajo de abstracción de la información.
Esta visión sólo la requiere el administrador/a. El administrador la necesita para poder gestionar más eficien-
temente la base de datos.
4. ¿Qué entiende por Nivel conceptual?

Se trata de un esquema teórico de los datos en el que figuran organizados en estructuras reconocibles del
mundo real y en el que también aparece la forma de relacionarse los datos. Este esquema es el paso que permi-
te modelar un problema real a su forma correspondiente en la base. Este esquema es la base de datos de todos
los demás. Como se verá más adelante es el primer paso a realizar al crear una base de datos.
El esquema conceptual lo realiza diseñadores/as o analistas.
Dicho de otra manera este nivel corresponde a la estructura organizacional de los datos de la base obtenida al
reunir los requerimientos de todos los usuarios de una empresa, sin preocuparse de su organización física ni las
vías de acceso.
5. ¿Qué entiende por Nivel físico?

Se trata de la visión de los datos que poseen los usuarios y usuarias finales. Esa visión es la que obtienen a través
de las aplicaciones. Las aplicaciones creadas por los desarrolladores abstraen la realidad conceptual de modo
que el usuario no conoce las relaciones entre los datos, como tampoco conoce todos los datos que realmente
se almacenan.
Realmente cada aplicación produce un esquema externo diferente (aunque algunos pueden coincidir) o vista
de usuario. El conjunto de todas las vistas de usuario es lo que se denomina esquema externo global.
6. Si hago un backup y restore de la estructura de la base no se hace un backup de los datos sino que de la estruc-
tura. ¿Qué es lo que se está copiando el diccionario de datos o la metadata?
La metadata documenta internamente, entre otras cosas, qué tablas existen en una base de datos, qué colum-
nas posee cada una de las tablas y qué tipo de datos se pueden almacenar. Así como los permisos, relaciones,
restricciones, todo lo referente a la estructura de la base.
7. ¿Qué hace específicamente el manejador de archivo de la base de datos?

Implementa los medios para obtener y analizar esos datos, para extraerlos, transformarlos y cargarlos, así como
las diferentes formas para realizar la gestión de datos son componentes esenciales de un almacén de datos
En esta definición se incluyen herramientas para la inteligencia empresarial, herramientas para extraer, trans-
formar y cargar datos en el almacén de datos, y herramientas para gestionar y recuperar los metadatos.
174
Base de Datos
8. El administrador de base de datos tiene documentada la estructura de datos en qué lugar.

En el diccionario de datos un listado organizado de todos los elementos de datos pertinentes al sistema, con
definiciones precisas y rigurosas para que el usuario y el analista de sistemas puedan conocer todas las entra-
das, salidas, componentes de depósitos y cálculos intermediarios.
1. ¿Qué es un sistema de gestión de base de datos?

Un sistema gestor de bases de datos o SGBD (aunque se suele utilizar más a menudo las siglas DBMS proce-
dentes del inglés, Data Base Management System) es el software que permite a los usuarios procesar, describir,
administrar y recuperar los datos almacenados en una base de datos.
En estos Sistemas se proporciona un conjunto coordinado de programas, procedimientos y lenguajes que per-
miten a los distintos usuarios realizar sus tareas habituales con los datos, garantizando además la seguridad de
los mismos.
2. Dentro de las características deseables ¿Qué entiende por Control de redundancia?

El SGBD consta de herramienta para crear restricciones para evitar duplicaciones. Ejemplo con los campos uni-
que o mismo con la primary key.
3. Para que solo los usuarios de la base de datos de recursos humanos vean los sueldos de la organización de que
característica del SGBD me voy valer.
Restricciones y autorizaciones como tenemos muchos usuarios que comparten la base pero no todos deben
tener acceso a toda la información que ella contiene. El SGBD debe contar con un subsistema de seguridad y
autorización que permita al DBA administrar restricciones y autorizaciones.
4. ¿Que característica del SGBD interviene implícitamente en lo cotidiano cuando en la oficina a las 9 de la maña-
na todos los usuarios se conectan con una misma base?
Suministro múltiple de interfaces con los usuarios.
Como podemos tener una gran variedad de usuarios y con diversos niveles de conocimientos el SGBD debe
contar con diferentes interfaces para los diferentes usuarios.
5. ¿Que característica del SGBD en una restricción de una tabla que si es menor de 17 años no me deje cargar el
número de la licencia de conducir?
Cumplimiento de las restricciones de integridad.
Cuando hablamos de restricciones de integridad nos referimos a restricciones de los datos que las aplicaremos
mediante el SGBD. La forma más fácil de restringir la integridad consiste en especificar un tipo de datos para
cada elemento de información. Ej el campo grado de primaria no va ser texto sino que numérico y a su ves no
va tener mas de una posición numérica ya que no tenemos grados de dos dígitos.
6. Dentro de las características deseables ¿Cómo explicaría en que consiste la recuperación y respaldo?
Respaldo y recuperación se refiere a la recuperación ante falla de hardware o software del SGBD. Si por algún
motivo el SGBD falla debe volver a la instancia anterior a la falla.
175
7. ¿Cuáles son los lenguajes que utiliza el SGBD?

Funciones y lenguajes de SGBD.
• Función de descripción o de definición: Permite al diseñador de la base de datos crear las estructuras apro-
piadas para integrar adecuadamente los datos. Esta función se realiza mediante el lenguaje de descripción
de datos o DDL.
• Función de manipulación: Permite modificar y utilizar los datos de la base de datos. Se realiza mediante el
lenguaje de modificación de datos o DML
• Función de control: Mediante esta función los administradores poseen mecanismos para proteger las vi-
siones de los datos permitidas a cada usuario. El lenguaje que implementa esta función es el lenguaje de
control de datos o DCL.
8. ¿Cuál es la función de la estructura multicapas del SGBD?

El proceso que realiza un SGBD está en realidad formado por varias capas que actúan como interfaces entre el
usuario y los datos. Este modelo toma como objeto principal al usuario habitual de la base de datos, su finali-
dad es ocultar y proteger la parte interna de las bases de datos.
1. Me proponen un trabajo para dar de alta usuarios en la base, realizar backups, controlar la performance y crear
restricciones. ¿Qué puesto es?
El trabajo que me están ofreciendo es de DBA administrador de base de datos.
2. Cuando no me puedo conectar a una base de datos ¿a quién debería llamar?

Debería llamar al equipo de mantenimiento encargados de dar soporte a los usuarios.
3. ¿En qué se diferencian básicamente los usuarios de base de datos?

Se diferencian básicamente en el uso que le dan a la base de datos. Los tipos de usuarios son 3:
• Expertos/as. Utilizan el lenguaje de manipulación de datos (DML) para acceder a la base de datos. Son usua-
rios que utilizan la base de datos para gestión avanzada de decisiones.
• Habituales. Utilizan las aplicaciones creadas por los desarrolladores para consultar y actualizar los datos
• Ocasionales. Son usuarios que utilizan un acceso mínimo a la base de datos a través de una aplicación que
permite consultar ciertos datos.
4. ¿Existe un estándar para los gestores de base de datos? Fundamentar.

El organismo ANSI ha marcado la referencia para la construcción de SGBD. El modelo definido por el grupo de
trabajo SPARC se basa en estudios anteriores en los que se definían tres niveles de abstracción necesarios para
gestionar una base de datos. ANSI profundiza más en esta idea y define cómo debe ser el proceso de creación
y utilización de estos niveles. En el modelo ANSI se indica que hay tres modelos: externo, conceptual e interno.
Se entiende por modelo, el conjunto de normas que permiten crear esquemas (diseños de la base de datos).
5. En qué consiste el proceso de creación de una base de dato propuesta por ANSI.
Proceso de creación y manipulación de una base de dato propuesta por ANSI.
Fase de creación
• El analista o diseñador crea el esquema conceptual.
• El administrador de la base de datos (DBA) crea el esquema interno.
• Los desarrolladores utilizan las aplicaciones necesarias para generar el esquema externo.
176
Base de Datos
6. En qué consiste el proceso de manipulación de una base de dato propuesta por ANSI.
• El usuario realiza una consulta utilizando el esquema externo.
• Las aplicaciones las traducen a su forma conceptual.
• El esquema conceptual es traducido por la SGBD a su forma interna.
• EL Sistema Operativo accede al almacenamiento físico correspondiente y devuelve los datos al SGBD.
• El SGBD transforma los datos internos en datos conceptuales y los entrega a la aplicación.
• La aplicación muestra los datos habiéndolos traducido en su forma externa. Así los ve el usuario.
7. Cuando saco dinero de un cajero automático, la operación de salida y actualización de saldo se hace en una
base de datos centralizada que no está en el mismo cajero. ¿Qué tipo de estructura operacional está en juego?
Estructura Cliente-Servidor. Estructura clásica, la base de datos y su SGBD están en un servidor al cual acceden
los clientes.
8. Cuando modifico mis datos en la pagina del banco (home banking) ¿Qué tipo de estructura operacional está
en juego?
Cliente-Servidor con facilidades de usuario-Servidor de base de datos. Se trata de una forma de conexión por
el que los clientes no conectan directamente con la base de datos sino con un intermediario (normalmente un
Servidor Web) que tiene una mayor facilidad para comunicarse con los usuarios.
1. ¿Qué entiende por modelo de datos?

Los modelos se utilizan en todo tipo de ciencias. Su finalidad es la de simbolizar una parte del mundo real de
forma que sea más fácilmente manipulable. En definitiva es un esquema mental (conceptual) en el que se in-
tentan reproducir las características de una realidad específica.
En el caso de los modelos de datos, lo que intentan reproducir es una información real que deseamos almace-
nar en un sistema informático.
Se denomina esquema a una descripción específica en términos de un modelo de datos. El conjunto de datos
representados por el esquema forma la base de datos.
2. ¿Cuál es la diferencia de los modelos conceptuales y lógicos?

El modelo conceptual es independiente del DBMS que se vaya a utilizar. El lógico depende de un tipo de SGBD
en particular.
El modelo conceptual es el más cercano al usuario, el lógico es el encargado de establecer el paso entre el mo-
delo conceptual y el modelo físico del sistema.
3. ¿Qué es un modelo de entidad-relación?

Está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados enti-
dades, y de relaciones entre estos objetos.
• Una entidad es una «cosa» u «objeto» en el mundo real que es distinguible de otros objetos.
• Los atributos describen propiedades que posee cada miembro de un conjunto de entidades.
• Una relación es una asociación entre varias entidades.
177
4. ¿Qué es un modelo orientado a objetos?

Desde la aparición de la programación orientada a objetos (POO u OOP) se empezó a pensar en bases de datos
adaptadas a estos lenguajes. La programación orientada a objetos permite cohesionar datos y procedimientos,
haciendo que se diseñen estructuras que poseen datos (atributos) en las que se definen los procedimientos
(operaciones) que pueden realizar con los datos. En las bases orientadas a objetos se utiliza esta misma idea.
A través de este concepto se intenta que estas bases de datos consigan arreglar las limitaciones de las relaciona-
les. Por ejemplo el problema de la herencia (el hecho de que no se puedan realizar relaciones de herencia entre
las tablas), tipos definidos por el usuario, disparadores (triggers) almacenables en la base de datos, soporte multi-
media. Se supone que son las bases de datos de tercera generación (la primera fue las bases de datos en red y la
segunda las relacionales), lo que significa que el futuro parece estar a favor de estas bases de datos. Pero siguen
sin reemplazar a las relacionales, aunque son el tipo de base de datos que más está creciendo en los últimos años.
Su modelo conceptual se suele diseñar en UML y el lógico actualmente en ODMG (Object Data Management
Group, grupo de administración de objetos de datos, organismo que intenta crear estándares para este modelo).
5. ¿Explique un modelo relacional?

El modelo relacional para la gestión de una base de datos es un modelo de datos basado en la lógica de predi-
cados y en la teoría de conjuntos. Es el modelo más utilizado en la actualidad para modelar problemas reales y
administrar datos dinámicamente.
6. ¿Explique un modelo de red?

Es un modelo que ha tenido una gran aceptación (aunque apenas se utiliza actualmente). En especial se hizo po-
pular la forma definida por Codasyl a principios de los 70 que se ha convertido en el modelo en red más utilizado.
El modelo en red organiza la información en registros (también llamados nodos) y enlaces. En los registros se
almacenan los datos, mientras que los enlaces permiten relacionar estos datos. Las bases de datos en red son
parecidas a las jerárquicas sólo que en ellas puede haber más de un padre.
En este modelo se pueden representar perfectamente cualquier tipo de relación entre los datos (aunque el
Codasyl restringía un poco las relaciones posibles), pero hace muy complicado su manejo.
7. ¿Explique un modelo Jerárquico?

Era utilizado por los primeros SGBD, desde que IBM lo definió para su IMS (Information Management System,
Sistema Administrador de Información) en 1970. Se le llama también modelo en árbol debido a que utiliza una
estructura en árbol para organizar los datos.
La información se organiza con un jerarquía en la que la relación entre las entidades de este modelo siempre es
del tipo padre / hijo. De esta forma hay una serie de nodos que contendrán atributos y que se relacionarán con
nodos hijos de forma que puede haber más de un hijo para el mismo padre (pero un hijo sólo tiene un padre).
Los datos de este modelo se almacenan en estructuras lógicas llamadas segmentos. Los segmentos se relacio-
nan entre sí utilizando arcos.
La forma visual de este modelo es de árbol invertido, en la parte superior están los padres y en la inferior los hijos.
8. Enumere los pasos para el diseño de una base de datos.

1. Planificación y definición del sistema.
2. Análisis de requerimientos.
3. Diseño conceptual.
4. Elección de SGBD.
5. Diseño lógico.
6. Diseño Físico.
7. Implementación.
8. Conversión y carga de datos y pruebas.
9. Ajuste de rendimiento.
178
Base de Datos
1. ¿Cuáles son los componentes del modelo entidad relación?

Entidad: objeto u elemento (real o abstracto) acerca del cual se pueda almacenar información en la base de
datos. Dentro de las entidades las podemos clasificar de sos tipos:
Regulares. Son las entidades normales que tienen existencia por sí mismas sin depender de otras.
Débiles. Su existencia depende de otras.
Relación: representan asociaciones entre entidades. Es el elemento del modelo que permite relacionar en sí los
datos del modelo.
Atributos: Propiedad o característica de una entidad.

Una entidad particular es descrita por los valores de sus atributos.
Clasificación de atributos
4. Opcionales
Dominio: conjunto de los posibles valores que puede tomar una cierta característica se denomina dominio.
2. Si se modela las propiedades de una entidad que se está modelando. Ejemplo dirección, teléfono y fecha de
nacimiento de empleado.
Se están modelando los atributos de dicha entidad.
3. De los alumnos de un colegio se tomo como atributo identificador primario el número de legajo que univoco,
también se guarda el DNI. Este último qué tipo de atributo seria en este contexto.
En ambos casos es un atributo clave.
En el ejemplo el legajo es el atributo identificador primario es clave univoca para identificar dicha entidad.
Mientras que el DNI es atributo identificador alternativo que también es univoca pero no se definió como pri-
maria.
4. En una agencia de micros de media distancia la clave univoca para identificar los viajes son el interno de micro,
el destino, la fecha y el chofer; debido a que van rotando todos los componentes. ¿Esta clave univoca como
estaría formada?
Es un atributo identificador compuesto ya que está compuesto por más de un atributo como clave univoca.
5. Si el atributo antigüedad de la entidad empleado la calculo con el atributo fecha de ingreso. ¿Qué tipos de
atributo son estos últimos?
Es un atributo derivado ya que es un valor calculado a partir de otra información ya existente.
6. Qué diferencia existe entre el atributo fecha de nacimiento de la entidad empleado, va tomar un único valor y
el atributo estudios cursados.
Uno la fecha de nacimiento es mono valorado va tomar un único valor mientras que estudios cursados puede
tomar de un único valor.
7. Si tengo una relación DICTA entre la entidad PROFESOR y MATERIA, y me dicen que el profesor solo puede dic-
tar una materia y cada materia puede ser dictada por un solo profesor ¿Qué tipo cardinalidad tiene?
8. ¿Cuál sería el dominio del atributo VOCALES de la entidad LETRA?

El dominio vocales de la entidad letra esta formado por { ‘a’ ; ‘e’ ; ’i’ ; ’o’ ; ‘u’}
179
1. ¿Qué son las relaciones ISA?

entidad.
Se utilizan para unificar entidades agrupándolas en una entidad más general (generalización) o bien para divi-
dir una entidad general en entidades más específicas (especificación). Aunque hoy en día a todas se las suele
llamar generalización e incluso relaciones de herencia.
Se habla de generalización si inicialmente partimos de una serie de entidades que al estudiarlas en detalle des-
cubrimos que todas ellas pertenecen al mismo conjunto, que será el que determine una nueva entidad. En la
generalización las entidades son totalmente heterogéneas, es decir, los atributos son diferentes. La entidad ge-
neral se llama superentidad las otras se denominan subentidades. En la superentidad se colocan los atributos
comunes a todas las subentidades. Y normalmente se la coloca una clave principal distinta de las subentidades
La especialización ocurre cuando partimos de una entidad que podemos dividir en subentidades para detallar
atributos que varían en las mismas. Comparten clave con la superentidad y los atributos de la superclase se
heredan en las subclases.
2. Si tengo las entidades libro y ejemplar con la interrelación tiene.
SI no tengo ningún libro no tengo ningún ejemplar.
¿Qué tipo de entidades son?

Libros es una entidad regular por que no depende de ninguna otra, mientras que ejemplar es una entidad débil
que depende de libro. Si no tengo ningún libro no tengo ningún ejemplar.
3. Estamos diseñando una base de datos para el área de recursos humanos de una empresa de services de televi-
sores, solo guardamos los datos de los empleados, DNI, nombre, apellido, dirección, teléfono y fecha de ingre-
so. Dentro de los empleados tenemos técnicos, chóferes y maestranza. Para los técnicos se necesita agregar a
los datos descriptos anteriormente el estudio cursado, mientras que para los chóferes el número de licencia de
conducir. Para el personal de maestranza el horario.
180
Base de Datos
Preguntas:
a) ¿Qué tipo de relación es si el personal puede ser técnico y chofer?
Relaciones de jerarquía solapada. Indican que un ejemplar de la superentidad puede relacionarse con más de
una subentidad (el personal puede ser técnico y chofer).
b) ¿Qué tipo de relación es si el personal no puede ser técnico y chofer?

subentidad (el personal no puede ser técnico y chofer).
c) ¿Qué tipo de relación es si hay personal que no es ni técnico, ni chofer ni maestranza?

Relaciones de jerarquía parcial. Indican que hay ejemplares de la superentidad que no se relacionan con ningu-
na subentidad (hay personal que no es ni técnico, no maestranza ni chofer).
d) ¿Qué tipo de relación es si no hay personal que no es ni técnico, ni chofer ni maestranza?

subentidad (no hay personal que no sea ni chofer, ni maestranza, ni técnico).
EJERCICIO 1
A partir del siguiente enunciado se desea realiza el modelo entidad-relación.
“Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de los clientes (nom-
bre, apellidos, dni, dirección y fecha de nacimiento). Cada producto tiene un nombre y un código, así como un
precio unitario. Un cliente puede comprar varios productos a la empresa, y un mismo producto puede ser com-
prado por varios clientes. Los productos son suministrados por diferentes proveedores. Se debe tener en cuenta
que un producto sólo puede ser suministrado por un proveedor, y que un proveedor puede suministrar diferen-
tes productos. De cada proveedor se desea conocer el cuit, nombre y dirección”.
Nombre Precio
N:M
1:M
(0,n) (0,n) (1,n) (m,n)


181
EJERCICIO 2
A partir del siguiente enunciado se desea realizar el modelo entidad-relación.
“Se desea informatizar la gestión de una empresa de transportes que reparte paquetes por toda España. Los
encargados de llevar los paquetes son los camioneros, de los que se quiere guardar el dni, nombre, teléfono, di-
rección, salario y población en la que vive. De los paquetes transportados interesa conocer el código de paquete,
descripción, destinatario y dirección del destinatario. Un camionero distribuye muchos paquetes, y un paquete
sólo puede ser distribuido por un camionero. De las provincias a las que llegan los paquetes interesa guardar el
código de provincia y el nombre. Un paquete sólo puede llegar a una provincia. Sin embargo, a una provincia
pueden llegar varios paquetes. De los camiones que llevan los camioneros, interesa conocer la matrícula, modelo,
tipo y potencia. Un camionero puede conducir diferentes camiones en fechas diferentes, y un camión puede ser
conducido por varios camioneros”.
Nombre Modelo
Direcciom
N:M Tipo
(0,n) (0,n)
Poblacion (0,1)
Distribuye 1:M
(1,n)
Destinatario
1:M
(0,m) (1,1)

182
Base de Datos
EJERCICIO 3
A partir del siguiente enunciado diseñar el modelo entidad-relación.
“Se desea diseñar la base de datos de un Instituto. En la base de datos se desea guardar los datos de los profeso-
res del Instituto (DNI, nombre, dirección y teléfono). Los profesores imparten módulos, y cada módulo tiene un
código y un nombre. Cada alumno está matriculado en uno o varios módulos. De cada alumno se desea guardar
el nº de expediente, nombre, apellidos y fecha de nacimiento. Los profesores pueden impartir varios módulos,
pero un módulo sólo puede ser impartido por un profesor. Cada curso tiene un grupo de alumnos, uno de los
cuales es el delegado del grupo”.
Nombre
Nombre
Dni Telefono
Direccion Fech_nac
(0,m)
(1,1)
1:M (1,n)
Apellido
(1:1) M:N Cursa
(1,n)
1:M
(1,n)
Imparte Modulo
Cod_modulo
183
EJERCICIO 4
“Se desea diseñar una base de datos para almacenar y gestionar la información empleada por una empresa de-
dicada a la venta de automóviles, teniendo en cuenta los siguientes aspectos: La empresa dispone de una serie
de coches para su venta. Se necesita conocer la matrícula, marca y modelo, el color y el precio de venta de cada
coche. Los datos que interesa conocer de cada cliente son el dni, nombre, dirección, ciudad y número de teléfo-
no: además, los clientes se diferencian por un código interno de la empresa que se incrementa automáticamente
cuando un cliente se da de alta en ella. Un cliente puede comprar tantos coches como desee a la empresa. Un
coche determinado solo puede ser comprado por un único cliente. El concesionario también se encarga de llevar
a cabo las revisiones que se realizan a cada coche. Cada revisión tiene asociado un código que se incrementa au-
tomáticamente por cada revisión que se haga. De cada revisión se desea saber si se ha hecho cambio de filtro, si
se ha hecho cambio de aceite, si se ha hecho cambio de frenos u otros. Los coches pueden pasar varias revisiones
en el concesionario”.
Modelo
Nombre
Dni
Color
1:M
Precio
Telefono (1,1)
1:M Pasa
Filtro (0,n)
Aceite Revision
Frenos
Cod_revision

184
Base de Datos
EJERCICIO 5
“La clínica “SAN PATRÁS” necesita llevar un control informatizado de su gestión de pacientes y médicos. De cada
paciente se desea guardar el código, nombre, apellidos, dirección, provincia, código postal, teléfono y fecha de
nacimiento. De cada médico se desea guardar el código, nombre, apellidos, teléfono y especialidad. Se desea lle-
var el control de cada uno de los ingresos que el paciente hace en el hospital. Cada ingreso que realiza el paciente
queda registrado en la base de datos. De cada ingreso se guarda el código de ingreso (que se incrementará auto-
máticamente cada vez que el paciente realice un ingreso), el número de habitación y cama en la que el paciente
realiza el ingreso y la fecha de ingreso. Un médico puede atender varios ingresos, pero el ingreso de un paciente
solo puede ser atendido por un único médico. Un paciente puede realizar varios ingresos en el hospital”.
Nombre
Cod_medico
Medico
Apellido
(1,1)
Atiende 1:M
Cod_paciente Nombre
(0,m)
1:M Apellido
Cod_ingreso
Habitacion Fecha

185
EJERCICIO 6
Se desea informatizar la gestión de una tienda informática. La tienda dispone de una serie de productos que
se pueden vender a los clientes.”De cada producto informático se desea guardar el código, descripción, precio
y número de existencias. De cada cliente se desea guardar el código, nombre, apellidos, dirección y número de
teléfono. Un cliente puede comprar varios productos en la tienda y un mismo producto puede ser comprado por
varios clientes. Cada vez que se compre un artículo quedará registrada la compra en la base de datos junto con la
fecha en la que se ha comprado el artículo. La tienda tiene contactos con varios proveedores que son los que su-
ministran los productos. Un mismo producto puede ser suministrado por varios proveedores. De cada proveedor
se desea guardar el código, nombre, apellidos, dirección, provincia y número de teléfono”.
Cod_producto
M:N Apellido
(0,m)
Descripcion
Direccion
(1,m) Telefono
Suministra M:N
(1,m)
Nombre
Proveedor
Cod_ingreso
Direccion
Telefono
Apellido

186
Base de Datos
1. ¿Cuál es el elemento más importante en el modelo relacional?

La relación o tabla según el modelo relacional el elemento fundamental es lo que se conoce como relación,
aunque más habitualmente se le llama tabla Codd definió las relaciones utilizando un lenguaje matemático,
pero se pueden asociar a la idea de tabla (de filas y columnas) ya que es más fácil de entender.
2. ¿Cuáles son los elementos de una relación?

Atributos. Referido a cada propiedad de los datos que se almacenan en la relación (nombre, dni,...).
Tuplas. Referido a cada elemento de la relación. Por ejemplo si una relación almacena personas, una tupla
representaría a una persona en concreto.
3. Es correcta la afirmación de que la idea de relación según el modelo de Codd, es lo mismo que la idea de rela-
ción en el modelo Entidad/Relación de Chen. Justifique.
Según Codd en el modelo relacional una relación, es lo que conocemos como tabla (o también array o matriz),
mientras que para Chen en el modelo Entidad/Relación de refiere al conector entre entidades.
4. Si hablo de los objetivos del modelo relacional y me refiero digo que la forma de almacenar los datos, no debe
influir en su manipulación lógica. ¿a que me estoy refiriendo?
Estamos hablando de la independencia física. Refiere a la forma de almacenar los datos, no debe influir en su
manipulación lógica.
5. Si defino el rango de edades de los trabajadores como: números enteros entre el 18 y el 65, para mi tabla em-
pleados. ¿Qué estoy definiendo?
Estoy definiendo el dominio el mismo contiene todos los posibles valores que puede tomar un determinado
atributo. Dos atributos distintos pueden tener el mismo dominio.
Un dominio en realidad es un conjunto finito de valores del mismo tipo. A los dominios se les asigna un nombre
y así podemos referirnos a ese nombre en más de un atributo.
Al darle el rango lo estoy definiendo por intensión
6. Si para mi tabla o relación de Vehículo tengo los siguientes campos: marca, modelo, patente, numero de motor
y numero de chasis.
a. ¿Qué tipo de claves utilizaría para reconocerlo unívocamente?
Como clave primaria puedo utilizar la patente o el número de motor o el número de chasis.
b. Identifique a las demás.
Marca y modelo son campos comunes y patente o el número de motor o el número de chasis las dos que no
son primarias son alternativos.
7. ¿Cuál es la diferencia entre tablas permanentes y temporales?

Persistentes. Sólo pueden ser borradas por los usuarios.
Temporales. Son tablas que se eliminan automáticamente por el sistema.
187
1. Si tengo dos tablas la primera: Empleado con los siguientes campos: numero de legajo pk, nombre, apellido,
antigüedad, dni. La segunda tabla salario_empleado tiene los siguientes campos: numero legajo, categoría.
¿Qué significancia tiene número de legajo en ambas tablas?
El número de legajo en la tabla empleado es la clave primaria y en la tabla salario_empleado es la clave foránea.
Por medio de este campo se pueden relacionar las dos tablas.
2. Estoy diseñando una base para una empresa de transportes y me piden ciertas restricciones (a,b,c) para la tabla
choferes los campos son los siguiente licencia de conducir, nombre, apellido, dirección, estado civil, teléfono y
DNI. ¿Qué tipo de restricciones son las siguientes?
a. Que no se repita el número de licencia de conducir ya que el identificador univoco.
El campo Licencia de conducir es clave primaria.
b. El número de documento no puede faltar.
Obligatoriedad el campo no permite nulos.
c. Estado civil no puede pasar de soltero a viudo.
Integridad referencial. El campo estado civil tiene restricciones impuestas por el usuario.
Corrección ejercitación modulo 11
Ejercicio 1
Nombre Precio
N:M
1:M
(0,n) (0,n) (1,n) (m,n)


Cliente dni Nombre apellido fecha_nac telefono
Compra dni cod_producto
producto cod_producto Precio nombre
proveedor cuit Nombre direccion cod_producto
188
Base de Datos
Ejercicio 2
Nombre Modelo
Direcciom
N:M Tipo
(0,n) (0,n)
Poblacion (0,1)
Distribuye 1:M
(1,n)
Destinatario
1:M
(0,m) (1,1)
Camion matricula Modelo potencia tipo
conduce matricula Dni
camionero dni Nombre telefono direccion poblacion salario
paquete cod_paquete destinatario descripcion direccion dni
proveedor cod_provedor Nombre cod_paquete
189
Ejercicio 3
Nombre
Nombre
Dni Telefono
Direccion Fech_nac
(0,m)
(1,1)
1:M (1,n)
Apellido
(1:1) M:N Cursa
(1,n)
1:M
(1,n)
Imparte Modulo
Cod_modulo
profesor dni Nombre telefono direccion
Alumno expediente Nombre apellido fecha_nac es_delegado
Cursa expediente cod_modulo
Modulo cod_modulo Dni
190
Base de Datos
Ejercicio 4
Modelo
Nombre
Dni
Color
1:M
Precio
Telefono (1,1)
1:M Pasa
Filtro (0,n)
Aceite Revision
Frenos
Cod_revision
Cliente dni Nombre telefono direccion ciudad
Coche matricula Modelo marca color precio dni
revision cod_revision Frenos aceite filtro matricula
191
Ejercicio 5
Nombre
Cod_medico
Medico
Apellido
(1,1)
Atiende 1:M
Cod_paciente Nombre
(0,m)
1:M Apellido
Cod_ingreso
Habitacion Fecha
Medico cod_medico Nombre apellido
Ingreso cod_ingreso Habitación fecha cod_medico cod_paciente
paciente cod_paciente Nombre apellido
192
Base de Datos
Ejercicio 6
Cod_producto
M:N Apellido
(0,m)
Descripcion
Direccion
(1,m) Telefono
Suministra M:N
(1,m)
Nombre
Proveedor
Cod_ingreso
Direccion
Telefono
Apellido
Cliente cod_cliente Nombre apellido direccion telefono
Compra cod_cliente cod_producto
producto cod_producto Existencia precio descripcion
proveedor cod_ingreso Nombre apellido direccion telefono cod_producto
193
1. ¿Qué entiende por normalización?

El principio fundamental reside en que las tablas deben referirse a objetos o situaciones muy concretas, rela-
cionados exactamente con elementos reconocibles por el sistema de información de forma inequívoca. Cada
fila de una tabla representa inequívocamente un elemento reconocible en el sistema. Lo que ocurre es que
conceptualmente es difícil agrupar esos elementos correctamente.
2. ¿Cuáles son las formas normales?

Las formas normales se corresponden a una teoría de normalización iniciada por el propio Codd y continuada
por otros autores (entre los que destacan Boyce y Fagin). Codd definió en 1970 la primera forma normal, desde
ese momento aparecieron la segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma normal.
Hay que tener en cuenta que muchos diseñadores opinan que basta con llegar a la forma Boyce-Codd, ya que
la cuarta, y sobre todo la quinta, forma normal es polémica.
3. ¿Cuál es la Primera forma normal - FN1?

Se dice que una tabla se encuentra en primera forma normal si impide que un atributo de una tupla pueda
tomar más de un valor.
4. ¿Qué entiende por dependencia funcional?

Se dice que un conjunto de atributos (Y) depende funcionalmente de otro conjunto de atributos (X) si para
cada valor de X hay un único valor posible para Y. Simbólicamente se denota por X -> Y.
5. ¿Qué entiende por dependencia funcional completa?

Y tiene dependencia funcional de X y además no se puede obtener de X un conjunto de atributos más peque-
ño que consiga una dependencia funcional de Y (es decir, no hay en X un determinante formado por atributos
más pequeños).
6. ¿Qué entiende por dependencia funcional elemental?

7. ¿Qué entiende por dependencia funcional transitiva?

Es más compleja de explicar, pero tiene también utilidad. Se produce cuando tenemos tres conjuntos de atri-
butos X, Y y Z. Y depende funcionalmente de X (X -> Y), Z depende funcionalmente de Y (Y -> Z). Además X no
depende funcionalmente de Y (Y-/ ->X). Entonces ocurre que X produce una dependencia funcional transitiva
sobre Z.
8. ¿Qué entiende por Segunda forma normal - FN2?

funcional completa respecto de cualquiera de las claves. Toda la clave principal debe hacer dependientes al
resto de atributos, si hay atributos que depende sólo de parte de la clave, entonces esa parte de la clave y esos
atributos formarán otra tabla.
9. ¿Qué entiende por Tercera forma normal - FN3?

Ocurre cuando una tabla está en 2FN y además ningún atributo que no sea clave depende transitivamente de
las claves de la tabla. Es decir no ocurre cuando algún atributo depende funcionalmente de atributos que no
son clave.
194
Base de Datos
Corrección ejercitación tema 12
Ejercicio 1
id_cliente nombre apellido contacto

1 jose garcia 47654222
2 enrique lopez 45367263
3 daniel perez 46736522, 43321234
id_cliente nombre apellido

1 jose garcia
2 enrique lopez
3 daniel perez
id_cliente contacto
1 47654222
2 45367263
3 43321234
3 46736522
Ejercicio 2
Dni nombre apellido Mail

22111232 lucas garcia [email protected]
33432123 cesar lopez clopez@hotmail
43456987 daniel perz [email protected], [email protected]
Dni nombre apellido

22111232 lucas garcia
33432123 cesar lopez
43456987 daniel perz
Dni Mail
22111232 [email protected]
33432123 clopez@hotmail
195
Ejercicio 3
id_gerente gerente direccion localidad id_localidad

22 gonzalez sarmiento 11 junin 1
43 ramirez jonte 322 azul 2
23 estevez san martin 31 capitan sarmiento 3
44 garcia belgrano 54 junin 1
id_gerente gerente direccion id_localidad

22 gonzalez sarmiento 11 1
43 ramirez jonte 322 2
23 estevez san martin 31 3
44 garcia belgrano 54 1
id_localidad localidad
1 junin
2 azul
3 capitan sarmiento
1 junin
Ejercicio 4
cod_libro titulo autor cod_editorial editorial

1 martin fierro j hernandez 2 lozada
2 la iliada homero 3 gredos
3 tragedias I herodoto 3 gredos
4 el facundo sarmiento 2 lozada
cod_libro titulo autor cod_editorial

1 martin fierro j hernandez 2
2 la iliada homero 3
3 tragedias I herodoto 3
4 el facundo sarmiento 2
cod_editorial editorial
2 lozada
3 gredos
196
Base de Datos
Ejercicio 5
vendedores
Dni nombre apellido factura importe
22111232 lucas garcia 2231123 100
33432123 cesar lopez 1342342 200
43456987 daniel perz 24353245 104
33432123 cesar lopez 1342343 204
Dni nombre apellido

22111232 lucas garcia
33432123 cesar lopez
43456987 daniel perz
Dni factura
22111232 2231123
33432123 1342342
43456987 24353245
33432123 1342343
factura importe
2231123 100
1342342 200
24353245 104
1342343 204
Ejercicio 6
articulos
cod_art articulo descrip_art material cod_material
22111232 vaso azul por 6 unid plastico 123
33432123 plato playo pirex 124
43456987 botella verde vidrio 125
33432123 copa noruega agua vidrio 125
cod_art articulo descrip_art cod_material cod_material material

22111232 vaso azul por 6 unid 123 123 plastico
33432123 plato playo 124 124 pirex
43456987 botella verde 125 125 vidrio
33432123 copa noruega agua 125 125 vidrio
197
1. Escribir la sintaxis para crear una base de datos llamada RRHH.

CREATE DATABASE rrhh
LOGFILE rrhh.log
MAXLOGFILES 25
MAXINSTANCES 10
ARCHIVELOG
CHARACTER SET WIN1214
NATIONAL CHARACTER SET UTF8
DATAFILE rrhh.dbf AUTOEXTEND ON MAXSIZE 500MB;
2. Escribir la sintaxis para crear la tabla empleados con los campos DNI numérico de 8, nombre carácter de 50,
apellido carácter 50.
CREATE TABLE empleados (
dni NUMERIC(8)
nombre VARCHAR(50)
apellido VARCHAR(50));
3. Escribir la sintaxis para modificar la tabla empleados y agregar la columna teléfono numérico de 20.
ALTER TABLE empleados ADD(
telefono NUMERIC(20));
4. Escribir la sintaxis para modificar de la tabla empleados el campo DNI y definirlo como clave primaria.
ALTER TABLE empleados (
dni NUMERIC(8)
nombre VARCHAR(50)
apellido VARCHAR(50)
telefono NUMERIC(20)
primary key(dni)
);
5. Escribir la sintaxis para crear la tabla salarios con los campos categoría carácter de 50, descripción carácter de
50, importe decimal de 8 enteros y 2 decimales.
CREATE TABLE salarios (
categoría VARCHAR(50)
descripción VARCHAR(50)
importe DECIMAL(8,2)
);
6. Escribir la sintaxis para borrar la columna descripción de la tabla salarios.

ALTER TABLE DROP(descripción);
7. Escribir las sintaxis para borrar las tablas empleados y salarios.

DROP TABLE salarios
DROP TABLE empleados
8. Escribir las sintaxis para borrar la base RRHH.

DROP DATABASE rrhh
198
Base de Datos
1. ¿Con qué clausula busco los campos de una tabla cuando sean nulos?
Con la cláusula where is null devuelve verdadero si el valor que examina es nulo.
SELECT campo
FROM tabla
WHERE campo is null
GO
2. ¿Con que clausula puedo realizar agrupaciones de campos?

La cláusula GROUP BY que permite indicar en base a qué registros se realiza la agrupación.
SELECT campo1, campo2
FROM tabla
Group By campo1, campo2
GO
3. ¿Cuál es el operador permite obtener datos que se encuentren en un rango?

El operador BETWEEN nos permite obtener datos que se encuentren en un rango.
SELECT campo
FROM tabla
WHERE campo BETWEEN 1 and 10
GO
4. ¿Cómo puedo buscar datos que se encuentran en una lista?

Permite obtener registros cuyos valores estén en una lista de valores.
SELECT campo
FROM tabla
WHERE campo in( 1,2,3,4)
GO
5. ¿Cómo se anula definitivamente los cambios, de una transacción?

La instrucción COMMIT hace que los cambios realizados por la transacción sean definitivos, irrevocables.
6. ¿Qué hace un ROLLBACK?

Esta instrucción regresa a la instrucción anterior al inicio de la transacción, normalmente el último COMMIT.
7. ¿Cómo puedo restringir el resultado de una expresión agrupada?

A veces se desea restringir el resultado de una expresión agrupada, para ello utilizamos la clausula having.
SELECT campo1, campo2
FROM tabla
Group By campo1, campo2
HAVING campo1 is not null
GO
8. ¿Qué utilizaría sintaxis utilizaría para mostrar ventas por regiones de la tabla ventas (región, sucursal, vendedor,
factura, importe)?
SELECT región, sum(importe)
FROM ventas
Group By región
GO
199
Corrección ejercitación tema 15
De las tablas:
CLIENTE(codigo,nombre,domicilio,provincia)
PRODUCTO(codigo_producto,nombre_producto)
ITEM_VENTAS(número_factura,codigo_producto,cantidad,precio)
VENTAS(numero_factura,codigo_cliente,fecha)
Responder con la sintaxis correcta.
1. Obtener el nombre y el domicilio de los clientes que viven en la provincia de Misiones.

SELECT Nombre, Domicilio
FROM Cliente
WHERE Provincia=’Misiones’
2. Obtener el nombre, domicilio y provincia de los clientes que viven en la provincia de Misiones o de Rio Negro.
SELECT Nombre, Domicilio, Provincia
FROM Cliente
WHERE Provincia=’Misiones’ OR Provincia=’Rio Negro’
3. Obtener el importe total en pesos por factura y producto, especificando el numero de factura, el código del
producto y el importe total.
SELECT numero_factura, codigo_producto, (precio * cantidad) as
Total
FROM item_ventas
4. Sobre la consulta 3, obtener solo el importe total para el producto a

Total
FROM item_ventas
WHERE codigo_producto =’a’
5. Sobre la consulta 3, obtener solo el importe total para las facturas mayores iguales a 2 y menores iguales a 5 y
solo para el producto código c
Total
FROM item_ventas
WHERE (numero_factura between 2 and 5)
AND (codigo_producto = ‘c’)
6. Sobre la consulta 3, obtener solo el importe total para los registros cuyo importe total sea mayor a 200
Total
FROM item_ventas
WHERE cantidad * precio > 200
7. Obtener un listado de las facturas realizadas especificando numero de factura, nombre del producto y cantidad
vendida
SELECT numero_factura, nombre_producto, cantidad
FROM Producto as p, item_ventas as iv
WHERE iv.codigo_producto=p.codigo_producto
200
Base de Datos
8. Obtener un listado de las facturas realizadas cuya cantidad sea mayor igual a 15 especificando numero de fac-
tura, nombre del producto y cantidad vendida
SELECT numero_factura, nombre_producto, cantidad
WHERE iv.codigo_producto=p.codigo_producto and cantidad > = 15
9. Obtener un listado de las facturas realizadas indicando número de factura, nombre del cliente, nombre del
producto, cantidad y precio y el importe total
SELECT item_ventas.Numero_factura, nombre_cliente,
nombre_producto, cantidad, precio, cantidad * precio as Total
FROM Cliente, Ventas, Item_Ventas, Producto
WHERE Cliente.codigo_cliente = Ventas.codigo_cliente AND
Ventas.numero_factura = Item_Ventas.Numero_factura AND
Item_Ventas.codigo_producto = Producto.codigo_producto
10. Obtener la cantidad de unidades máxima

SELECT MAX(cantidad) as Cantidad
FROM item_ventas
11. Obtener la cantidad total de unidades vendidas del producto c

SELECT SUM(cantidad) as TOTAL
FROM item_ventas
Where codigo_producto = ‘c’
12. Cantidad de unidades vendidas por producto, indicando la descripción del producto, ordenado de mayor a
menor por las cantidades vendidas
SELECT nombre_producto AS Producto, sum(cantidad) as Cantidad
WHERE iv.codigo_producto = p.codigo_producto
GROUP BY nombre_producto
ORDER BY sum(cantidad) Desc
13. Cantidad de unidades vendidas por producto, indicando la descripción del producto, ordenado alfabética-
mente por nombre de producto para los productos que vendieron mas de 30 unidades.
SELECT nombre_producto AS Producto, sum(cantidad) as Cantidad
WHERE iv.codigo_producto = p.codigo_producto
GROUP BY nombre_producto
HAVING sum(cantidad) > 30
ORDER BY nombre_producto
14. Obtener cuantas compras (1 factura = 1 compra) realizo cada cliente indicando el código y nombre del cliente
ordenado de mayor a menor.
SELECT v.codigo_cliente, nombre_cliente, count (numero_factura)
as compras
FROM cliente as c, ventas as v
WHERE v.codigo_cliente = c.codigo_cliente
GROUP BY v.codigo_cliente, nombre_cliente
ORDER BY count(numero_factura) Desc
201
15. Promedio de unidades vendidas por producto, indicando el codigo del producto para el cliente 1.
SELECT codigo_producto, avg(cantidad) as promedio
FROM Ventas as v, item_ventas as iv
WHERE iv.numero_factura = v.numero_factura
AND codigo_cliente=1
GROUP BY codigo_producto
16. Cantidad de unidades vendidas por cliente y producto, indicando el nombre del cliente, la descripción del
producto para los productos que vendieron entre 15 y 35 unidades.
SELECT nombre_cliente, nombre_producto, SUM(cantidad) as
Unidades
FROM cliente as c, Producto as p , item_ventas as iv, ventas as v
WHERE c.codigo_cliente = v.codigo_cliente and
v.numero_factura = iv.numero_factura and
iv.codigo_producto = p.codigo_producto
GROUP BY nombre_cliente, nombre_producto
HAVING SUM(cantidad) between 15 and 35
1. ¿Con cuales tipos de bases de datos esta diseñado SQL Server para trabajar?
SQL Server está diseñado para trabajar con dos tipos de bases de datos:
• OLTP (OnLine Transaction Processing) Son bases de datos caracterizadas por mantener una gran cantidad
de usuarios conectados concurrentemente realizando ingreso y/o modificación de datos. Por ejemplo:
entrada de pedidos en línea, inventario, contabilidad o facturación.
• OLAP (OnLine Analytical Processing) Son bases de datos que almacenan grandes cantidades de datos que
sirven para la toma de decisiones, como por ejemplo las aplicaciones de análisis de ventas.
2. ¿Sobre qué sistemas operativos puede instalarse el sql server?

SQL Server puede ejecutarse sobre redes basadas en Windows Server así como sistema de base de datos de
escritorio en máquinas Windows NT Workstation, Windows Millenium y Windows 98.
3. Después de colocar el CD de instalación aparece la siguiente pantalla aparece una ventana que da la bienvenida
al proceso de instalación, al pasar a la siguiente pantalla que dos opciones de instalaciones nos ofrece el Wieser.
Nos da dos opciones instalación en computadora local o remota.
4. Luego de aceptar las condiciones del licenciamiento aparecerá una caja de diálogo solicitándole que seleccio-
ne uno de los tipos de instalación, cuales son los tipos de instalación.
Sólo Herramientas Cliente (Client Tools only), cuando requiera instalar herramientas clientes para administrar
un servidor SQL Server existente, así como también los componentes de conectividad los libros en línea y op-
cionalmente los ejemplos.
Servidor y Herramientas Cliente (Server and Client Tools), selecciona esta opción cuando requieras instalar un
servidor SQL Server 2000, el cual deba contar con todas las herramientas.
202
Base de Datos
Sólo Conectividad (Connectivity Only), seleccione esta opción para instalar las librerías de conectividad para
los clientes.
Para cualquiera de las tres opciones se instalará previamente MDAC 2.6, para la instalación que estamos reali-
zando seleccione Servidor y Herramientas Cliente (Server and Client Tools) y luego pulse Siguiente (Siguiente).
5. Cuando tenemos que seleccionar el tipo de instalación que debemos seleccionar para ver los espacios reque-
ridos así como también las carpetas donde se almacenaran las diferentes librerías de SQL Server.
Debo seleccionar Personalizada (Custom) para que pueda observar las diferentes opciones que configura el
instalador, en esta primera pantalla se muestran los espacios requeridos así como también las carpetas donde
se almacenaran las diferentes librerías de SQL Server:
6. ¿Cuál es el puerto de tcp/ip que debemos seleccionar?

El puerto de tcp/ip es 1433.
7. ¿Cómo verifica la instalación de SQL Server?

Una vez finalizada la instalación debe revisar la instalación para cerciorarse que el producto se ha instalado co-
rrectamente para ello puede mostrar el Administrador de Servicios (Service Manager) que le permitirá mostrar
el estado de los servicios.
8. ¿De qué otra manera se puede verificar los servicios?

Otra manera de poder verificar la instalación de SQL Server es revisar los servicios que se cargan, para ello voy
a menú Inicio / Programas / Herramientas Administrativas / ServiciosServices.
203
Índice Metadatos 25
Diccionario de datos 25
UNIDAD 1 Almacenamiento físico de bases de datos 25
Tema1: Introducción 6 Técnicas de almacenamiento y recuperación
¿Qué es un sistema de información? 6 de bases de datos 25
Impacto de los sistemas de información 7 El almacenamiento en archivos de las bases
Categorías de los sistemas de información 7 de datos 26
Sistemas de información computarizados 8 Unidades de almacenamientos - Discos Rígidos 26
Componentes estructurales de los sistemas Estructura física 27
de información computarizados 9 Direccionamiento 27
Entradas 9 Tipos de conexión 28
Modelos o Procesos 9 Resumen tema 3 28
Salida 9 Autoevaluación 29
Tecnología o hardware 10 Investigación: 30
Almacenamiento (Archivos o bases de datos) 10
Controles y seguridad 10 UNIDAD 2
Requerimientos de los sistemas de información TEMA 4: Sistema gestor de base de datos 32
computarizados 10 Características deseables en un SGBD 32
Requerimientos de sistemas 10 Control de redundancia 33
Requerimientos de procesamientos de datos 10 Restricción de accesos no autorizados 33
Requerimientos de factibilidad 10 Inferencias en la BD mediante reglas
Resumen tema 1 11 de deducción 33
Autoevaluación 12 Suministro múltiple de interfaces
Investigación 12 con los usuarios 33
Vínculos complejos entre los datos 33
TEMA 2: Base de datos 13 Cumplimiento de las restricciones de integridad 33
Evolución de los Sistemas de Bases de Datos 13 Respaldo y recuperación 33
Primeros Sistemas de Base de Datos 14 Funciones y lenguajes de SGBD 33
Principales características de las bases de datos 14 Función de descripción o de definición 34
Independencia lógica y física de los datos 15 Función de manipulación 34
Control centralizado de los datos 15 Estructura multicapas del SGBD 34
Integridad de los datos 15 Funcionamiento del SGBD 35
Minimización de redundancias 15 SGBD Comerciales 36
Independencias de los datos y las aplicaciones 15 MySQL: 36
Acceso concurrente a los datos 15 Oracle: 36
Componentes de un sistema de base de datos 15 Microsoft SQL Server: 36
Tipos de base de datos 16 Microsoft Access: 37
Bases de datos jerárquicas 16 DB2: 38
Bases de datos de red 17 Visual FoxPro: 38
Base de datos Relacional 17 PostgreSQL 39
Bases de datos multidimensionales 18 Resumen tema 4 40
Bases de datos orientadas a objetos 20 Autoevaluación 41
Resumen tema 2 21 Investigación 41
Autoevaluación 22
Investigación 22 TEMA 5: Usuarios de los GSBD 41
Estándar ANSI/SPARC, SGBD 42
TEMA 3: Arquitectura de la base de datos 23 El Nivel Externo 42
Niveles de abstracción de una base de datos 23 El Nivel Conceptual 43
Esquema físico 24 El Nivel interno 44
Esquema Conceptual 24 Proceso de creación y manipulación de una
Esquema o nivel externo 24 base de dato propuesta por ANSI 46
Manejador de archivo 25 Estructuras operacionales de los SDGB 47
204
Base de Datos
Características de una estructura cliente servidor 47 TEMA 9: Diseño de un modelo

Partes de una estructura cliente servidor 48 de entidad relación 82
La sección frontal o Frot- end 48 Resumen tema 9 88
La sección posterior o Back - end 50 Ejercitación 89
Situación del Mercado de los SGBD Investigación 90
y Estandarización 51
Resumen tema 5 51 TEMA 10: Modelo relacional 91
Autoevaluación 53 Objetivos 91
Investigación 53 Relación o tabla 91
Tupla 92
TEMA 6: Diseño de base de datos 54 Dominio 92
Modelo de datos 55 Grado 93
Diferencias entre el diseño lógico y conceptual 56 Cardinalidad 93
Modelos conceptuales 56 Sinónimo 93
Modelo de datos entidad-relación (MER) 56 Definición formal de relación 93
Modelos Lógicos 58 Propiedades de las tablas o relaciones 94
Modelo relacional 58 Tipos de tablas 94
Modelo jerárquico 59 Claves 94
Modelo de Red 59 Clave Candidata 94
Resumen tema 6 60 Clave Primaria 94
Autoevaluación 60 Clave Alternativa 94
Investigación 60 Clave externa, ajena o secundaria 94
Nulos 95
UNIDAD 3 Resumen tema 10 96
TEMA 7: Modelo entidad relación 62 Autoevaluación 97
Objetos del modelo 62 Investigación 97
Entidad 62
Conjunto de entidades 62 TEMA 11: Restricciones 98
Representación gráfica de las entidades 63 Inherentes 98
Relaciones 63 Semánticas 98
Qué es una relación 63 Las doce reglas de Codd 99
Representación gráfica 64 Pasaje de modelo entidad/relación
Grado de un tipo de relación 64 a modelo relacional 100
Papel o rol 65 Transformación de entidades fuertes 101
Correspondencia de cardinalidades 65 Transformación de relaciones 101
Cardinalidad 66 Resumen tema 11 105
Atributos 69 Autoevaluación 107
Clasificación de atributos 69 Ejercitación 107
Atributos Clave 69 Investigación 110
Dominio 71
Resumen tema 7 72 TEMA 12: Normalización 111
Autoevaluación 72 Formas normales 111
Investigación 72 Primera forma normal - FN1 112
Dependencia funcional 112
TEMA 8: Modelo entidad relación extendido 73 Dependencia funcional completa 112
Relaciones ISA o de herencia 73 Dependencia funcional elemental 113
Tipos relaciones ISA 75 Dependencia funcional transitiva 113
Entidades débiles 76 Segunda forma normal - FN2 113
Control de redundancias 78 Tercera forma normal - FN3 114
Resumen tema 8 80 Forma Normal Boyce-Codd (BCNF or FNBC) 114
Autoevaluación 81 Cuarta forma normal – FN4
Investigación 81 Dependencias multuvaluadas 115
205
Quinta forma normal – FN5 117 Agrupaciones 140

Resumen tema 12 118 Funciones cálculo de grupo 140
Ejercitación 120 Clausula Having 141
Investigación 121 Resumen tema 14 141
Autoevaluación 143
UNIDAD 4 Investigación 143
TEMA 13: SQL, DDL y DML 123
Historia del SQL 124 TEMA 15: Ejemplos de lo aprendido 144
Funcionamiento del SQL 124 Ejercitación 152
Ejecución directa sql interactivo 124 Investigación 152
Ejecución embebida 124
Ejecución entre cliente gráficos 125 TEMA 16: Introducción a SQL Server 2000 153
Ejecución dinámica 125 Modos de autenticar
Proceso de las instrucciones 125 las cuentas de los usuarios 165
Elementos del lenguaje SQL 125 Inicio de sesión 165
DDL 126 Usuarios de Base de Datos 168
Creación de base de datos 126 Investigación 170
Objetos de la base de datos 126 Bibliografía 170
Creación de tablas 126
Tipos de datos 127 Corrección autoevaluación tema 1 172
Blob - Binary large object 128 Corrección autoevaluación tema 2 173
Dominio 128 Corrección autoevaluación tema 3 174
Modificación – Alter 129 Corrección autoevaluación tema 4 175
Eliminación – Drop 129 Corrección autoevaluación tema 5 176
Restricciones 129 Corrección autoevaluación tema 6 177
Restricciones PRIMARY KEY 129 Corrección autoevaluación tema 7 179
Restricciones UNIQUE 130 Corrección autoevaluación tema 8 180
Restricciones FOREIGN KEY 130 Corrección autoevaluación tema 9 181
Definiciones DEFAULT 130 Corrección autoevaluación tema 10 187
Restricciones CHECK 131 Corrección autoevaluación tema 11 188
Reglas que aceptan valores NULL Corrección ejercitación tema 11 188
en la definición de una tabla 131 Corrección autoevaluación tema 12 194
Resumen tema13 132 Corrección ejercitación tema 12 195
Ejercitación 134 Corrección autoevaluación tema 13 198
Investigación 134 Corrección autoevaluación tema 14 199
Corrección ejercitación tema 15 200
TEMA 14: DML 135 Corrección autoevaluación tema 16 202
Inserción 135
Actualización 135
Borrados de registros 136
Instrucciones de control
de transacciones (DTL) 136
Commit 136
Rollback 136
Estado de los datos mientras la transacción 137
Consultas de datos con SQL - DQL 137
Cálculo 137
Condiciones 138
Between 139
In 139
Like 139
Is null 140
206

Modulo Completo Diseño y Administracion

Cargado por

Copyright:

Formatos disponibles

Modulo Completo Diseño y Administracion

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modulo Completo Diseño y Administracion

Cargado por

Copyright:

Formatos disponibles

Analista de

Unidad Nº 1: Introducción a las bases de datos

Unidad Nº 2: Sistema gestor de base de datos

Unidad Nº 4: SQL, DDL y SML

1. Introducción a las bases de datos

¿Qué es un sistema de información?

Impacto de los sistemas de información

Entre las ventajas de la utilización de un sistema de información computarizado:

• Control más efectivo de las actividades de la organización.

Entre las desventajas se puede encontrar:

• El tiempo que pueda tomar su implementación.

Categorías de los sistemas de información

2. Sistema de información gerencial o administrativa: (Produce reportes estructurados). Es un tipo de sistema

Sistemas de información computarizados

Componentes estructurales de los sistemas de información computarizados

Ejemplos de entradas de datos mediante diferentes medios o captura de los mismos:

Las entadas pueden ser de dos tipos:

• Exactitud: el resultado no debe tener desvíos.

Almacenamiento (Archivos o bases de datos)

• Backups de los datos (copias de respaldo).

Requerimientos de los sistemas de información computarizados

Requerimientos de procesamientos de datos

Componentes de un Sistema de información computarizado

Operaciones y procedimientos Métodos y los medios

Gráfico 2 – Componentes de un Sistema de información computarizado.

Resumen de Requerimientos que deben cumplir de los sistemas de información computarizados.

Sistema Procesamiento Factibilidad

Confiabilidad Volumen Técnica

Disponibilidad Complejidad Legal

Flexibilidad Restricciones de tiempo Operacional

Programa instalación Demandas computacionales De programa

Cuadro 1 – Requerimientos de un Sistema de información computarizado.

Evolución de los Sistemas de Bases de Datos

Primeros Sistemas de Base de Datos

Principales características de las bases de datos

1. Independencia lógica y física de los datos.

Independencia lógica y física de los datos

Independencia física de los datos

Independencia lógica de los datos

Control centralizado de los datos

Integridad de los datos

Independencias de los datos y las aplicaciones

Acceso concurrente a los datos

Componentes de un sistema de base de datos

Tipos de base de datos

• Bases de datos jerárquicas

Bases de datos jerárquicas

Gráfico 3 – Base de datos jerárquica.

Bases de datos de red

Gráfico 4 – Base de datos red.

Base de datos Relacional

• Una base de datos relacional se compone de varias tablas o relaciones.

Bases de datos multidimensionales

Visualización de los datos mediante un cubo

Ejemplo ventas de productos en diferentes regiones:

Gráfico 6 – Base de datos multidimensional – Tabla región.

Gráfico 7 – Base de datos multidimensional – Tabla región en el tiempo.

Gráfico 8 – Base de datos multidimensional – Dimensiones región y tiempo.

Bases de datos orientadas a objetos