Basesde datos

Vicerrectoría Académica
Proyecto P.A.V.
Plataforma de Aprendizaje Virtual

MÓDULO VIRTUAL BASES DE DATOS
ORALIA CORTÉS GRAJALES
VICERRECTORÍA ACADÉMICA
PROYECTO P.A.V.
PLATAFORMA DE APRENDIZAJE VIRTUAL
TECNOLÓGICO DE ANTIOQUIA
INSTITUCIÓN UNIVERSITARIA
MEDELLÍN
2008

Realización
Realización
Vicerrector Académico
John Harvey Garavito Londoño
Docente (Autor)
Oralia Cortés Grajales
Equipo Técnico P.A.V.
Nubia Amparo Giraldo García
Jhonatan Arroyave Jaramillo
Giselle Andrea Tamayo Mármol
Tecnológico de Antioquia Institución Universitaria
Plataforma de Aprendizaje Virtual
Proyecto P.A.V.
2008

Unidad 1
Introducción a los Sistemas
de Bases de Datos
En esta unidad se da a conocer globalmente los conceptos de lo que es
un sistemas de de bases de datos, ya que estas proporcionan la
infraestructura requerida para los sistemas de apoyo a la toma de
decisiones y para los sistemas de información estratégicos, es muy
importante tener claros los conceptos generales de bases de datos
antes de empezar a estudiar las diferentes etapas que permiten
desarrollar una base de datos.

1. Historia
1.1. Historia
El término base de datos fue acuñado por primera vez en 1963, en un simposio celebrado
en California. De forma sencilla podemos indicar que una base de datos no es más que un
conjunto de información relacionada que se encuentra agrupada o estructurada. El archivo
por sí mismo, no constituye una base de datos, sino más bien la forma en que está
organizada la información es la que da origen a la base de datos. Las bases de datos
manuales, pueden ser difíciles de gestionar y modificar. Por ejemplo, en una guía de
teléfonos no es posible encontrar el número de un individuo si no sabemos su apellido,
aunque conozcamos su domicilio. Del mismo modo, en un archivo de pacientes en el que la
información esté desordenada por el nombre de los mismos, será una tarea bastante
engorrosa encontrar todos los pacientes que viven en una zona determinada. Los problemas
expuestos anteriormente se pueden resolver creando una base de datos informatizada.
Desde el punto de vista informático, una base de datos es un sistema formado por un
conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un
conjunto de programas que manipulan ese conjunto de datos. Desde el punto de vista más
formal, podríamos definir una base de datos como un conjunto de datos estructurados,
fiables y homogéneos, organizados independientemente en máquina, accesibles a tiempo
real, compartibles por usuarios concurrentes que tienen necesidades de información
diferente y no predecible en el tiempo.
2

2. Conceptos Básicos de bases de
datos
2.1. Conceptos Básicos de bases de datos
Bit: 0 o 1
Byte: conjunto de bits
Campo: Conjunto de bytes la unidad más pequeña a la cual uno puede referirse en
un programa.
Registro: Colección de campos de iguales o de diferentes tipos.
Archivo: Colección de registros almacenados siguiendo una estructura homogénea.
Base de datos: Es una colección de archivos interrelacionados
Campo clave: Es un campo particular dentro del registro, que permite la
identificación exclusiva y unívoca de cada registro. La clave debe ser un valor que no
se repita, como por ejemplo, el número de cédula de identidad, número de
identificación, el número de carné en una universidad o el número de seguro social.
Enlace: Relación entre una secuencia de nodos, en los que se guardan campos de
datos
Estructura de datos de árbol: Es una forma de organizar un conjunto de datos
elementales con el objetivo de facilitar su manipulación la organización solo sigue una
jerarquía un nodo proviene de un solo nodo.
Estructura de datos en red: Es igual a la estructura de datos en árbol, su
diferencia está en que un nodo proviene de varios nodos.
Diagramas de estructura de datos: Es una descripción de la relación entre
entidades (personas, lugares, eventos y objetos) de un sistema y el conjunto de
información relacionado con la entidad.
Algoritmo: Un algoritmo es el conjunto de operaciones y procedimientos que deben
seguirse para resolver un problema
3

3. Definiciones de Base de datos
3.1. Definiciones de Base de datos
1. Conjunto de archivos interrelacionados entre ellos.
2. Sistema para archivar en computador, cuyo propósito es mantener la información y
hacer que esté disponible cuando se necesite.
3. Conjunto de información (conjunto de datos) que se encuentra agrupada o
estructurada.
4. Instrumento que supone un enfoque distinto en la gestión de datos.
5. Un conjunto de información almacenada en memoria auxiliar que permite acceso
directo y un conjunto de programas que manipulan esos datos.
6. Conjunto exhaustivo no redundante de datos estructurados organizados
independientemente de su utilización y su implementación en máquina accesibles en
tiempo real y compatibles con usuarios concurrentes con necesidad de información
diferente y no predicable en tiempo .
7. Una base de datos es un conjunto de datos que pertenecen al mismo contexto
almacenados sistemáticamente para su uso posterior. En este sentido, una biblioteca
puede considerarse una base de datos compuesta en su mayoría por documentos y
textos impresos en papel e indexados para su consulta .
8. conjunto de registros, homogéneos, ordenados de una forma determinada,
almacenados en soporte magnético u óptico y accesibles por ordenador
9. Se refiere a la estructura y la forma en que se guardará la información de una
empresa. Las bases de datos reflejan la organización de la información de la empresa
y por lo general se encuentran centralizadas físicamente en él o los servidores
principales_.
. Ibid., p. 6.
. Bases de datos. Obtenido en Internet el 22 agosto de 2008. Hora: 10.42 pm.
http://www.icapax.com/ASP/bases_de_datos.asp
.PÉREZ ÁLVAREZ-OSSORIO, J.R. Introducción a la información y documentación científica.
Madrid: Alambra, 1988. p.39
. Términos de naturaleza comunicativa e informática. Obtenido en Internet el 22 agosto de
2008. Hora: 10.42 pm.
http://www.colombiestad.gov.co/index.php?option=com_glossary&func=display&Itemid=25
&catid=114
4

4. Tipos de bases de datos
4.1. Tipos de bases de datos
Existen varias alternativas para diseñar las bases de datos:
JERARQUÍA O ÁRBOL: Puede representar dos tipos de relaciones entre los datos:
relaciones de uno a uno y relaciones de uno a muchos.
RED O GRAFO: Este modelo permite la representación de muchos a muchos, de tal
forma que cualquier registro dentro de la base de datos puede tener varias
ocurrencias superiores a él. El modelo de red evita redundancia en la información, a
través de la incorporación de un tipo de registro denominado el conector.
MODELO RELACIONAL: Este modelo se está empleando con más frecuencia en la
práctica, debido a las ventajas que ofrece sobre los dos modelos anteriores, entre
ellas, el rápido entendimiento por parte de usuarios que no tienen conocimientos
profundos sobre Sistemas de Bases de Datos.
BASES DE DATOS ORIENTADAS A OBJETOS (BDOO): Las BDOO almacenan y
manipulan información que puede ser digitalizada (representada) por objetos,
proporcionan una estructura flexible con acceso ágil, rápido, con gran capacidad de
modificación.
Además combina las mejores cualidades de los archivos planos, las bases jerárquicas y
relacionales.
BASES DE DATOS DISTRIBUIDAS. Las bases de datos distribuidas se están
utilizando cada vez más en la misma medida en que se usan las arquitecturas de
cliente-servidor y groupware. Los principales problemas que se generan por el uso de
la tecnología de bases de datos distribuidas son en lo referente a duplicidad de datos
y a su integridad al momento de realizar actualizaciones a los mismos. Además, el
control de la información puede constituir una desventaja, debido a que se encuentra
diseminada en diferentes localidades geográficas.
TENDENCIAS FUTURAS. En el futuro la mayoría de las organizaciones cambiarán la
forma convencional de manejo de la información a la arquitectura de base de datos a
las ventajas derivadas de su uso. El uso de las bases de datos distribuidas se
incrementará de manera considerable en la medida en que la tecnología de
comunicación de datos brinde más facilidades para ello. El uso de bases de datos
facilitará y soportará en gran medida a los Sistemas de Información para la Toma de
decisiones.
. Ibíd., p. 6.
5

5. Componentes que integran un
sistema de base de datos
5.1. Componentes que integran un sistema de base
de datos
1. Datos: cualquier cosa.
2. Información: Son los datos organizados y presentados de tal manera que resulten
de utilidad para la toma de decisiones en la empresa en la cual debe servir el
sistema.
3. Equipo: Donde se conservan los datos almacenados, el procesador y la memoria
principal hacen posible la ejecución de los programas del sistema de base de datos.
4. Programas: Permiten la implantación, acceso y mantenimiento del sistema de base
de datos. Así como la definición, actualización y recuperación de los datos
estructurados. Estos programas componen el DBMS sistema manejador de base de
datos (Data Base Management System) o también SGBD (Sistema Gestor de Base de
Datos).
5. Usuarios: Son las personas que interactúan con la base de datos
Hay dos clases de usuarios:
Informáticos: Tienen a su cargo las tareas de creación y mantenimiento de la base
de datos así como la realización de los procedimientos y programas que necesitan los
usuarios finales estos son:
o Diseñador: Recoge y organiza los datos en un modelo
o Programadores de aplicaciones: son los que desarrollan los programas de
interfase con los usuarios finales y acceden a la base de datos usando DML.
o Administrador de base de datos (DBA): Es un experto que gestiona la
base de datos.
Es la persona encargada de la administración de las bases de datos y tiene las
siguientes funciones:
Instala y actualiza el software
Saca copias de seguridad
Da soporte a todos los usuarios
Revisa las tareas diarias sobre la base de datos
6

Definición del esquema: es decir la creación del esquema original de
la base de datos. Esto lo hace escribiendo una serie de definiciones en
lenguaje DDL lo que genera las tablas y lo graba en el diccionario de
datos.
Definición de la estructura de almacenamiento y del método de
acceso: esto se lleva a cabo escribiendo una serie de definiciones con
el mismo DDL
Modificación del esquema y de la organización física: ya sea la
modificación del esquema de la base de datos o de la descripción de la
organización física del almacenamiento. Estos cambios, aunque son
poco frecuentes, se hacen usando DDL, compilándolas y aplicándolas al
diccionario de datos.
Concesión de autorización para el acceso de datos: es decir
administrar la seguridad de la base de datos, o sea conceder acceso o
denegarlo a un usuario en particular.
Especificación de las limitantes de integridad: estas limitantes se
conservan en una estructura especial del sistema que consulta el
manejador de bases de datos cada vez que se lleva a cabo una
actualización a un dato de la base de datos.
Finales: Su interés está centrado en el contenido da la base de datos estos pueden
ser:
o Sofisticados: utilizan lenguajes de consulta de base de datos
o Ingenuos: Utilizan interfaces y menús creados por los usuarios especializados
7

6. Ventajas y desventajas de una
base de datos
6.1. Ventajas de las bases de datos
Disminuir redundancia e inconsistencia de los datos: Puesto que los archivos y
los programas de aplicaciones fueron creados por distintos programadores en un
periodo largo, es posible que un mismo dato este repetido en varios sitios. Esta
redundancia aumenta los costos de almacenamiento y acceso, además incrementa la
posibilidad que exista inconsistencia en la información, es decir que las distintas
copias de la información no concuerden entre sí. Por ejemplo: si un sistema graba
información de sus clientes en el archivo de facturación y también maneja datos de
clientes en un archivo de servicio postventa, entonces un cliente podría tener sus
datos en dos archivos diferentes. Esto genera dos problemas: el primero es que
estamos gastando el doble de espacio en disco para grabar la misma información y el
otro es que si ese cliente cambia de domicilio y solo se cambia en el archivo de
facturación entonces la información será inconsistente pues en el archivo de servicio
postventa estará la información anterior, o sea que se tienen dos datos diferentes
para el mismo individuo.
Facilidad para tener acceso a los datos: suponga que el gerente de la empresa
llamada Aceites Esenciales S.A. desea saber la información de todos los clientes que
consumieron Extracto de manzanilla durante los primeros tres meses del año en
curso, ordenados por municipio. Ante un requerimiento de estos que no estaba
contemplado en el sistema original, tocaba hacer dos cosas; sacar el listado completo
de todos los clientes y extraerlos manualmente o sentar a un programador por una
semana o más para que haga el programa para hacer la consulta. La pregunta
esencial es y que se va a hacer la siguiente vez que se requiera una consulta que no
estaba inicialmente prevista?
Aislamiento o independencia de los datos: puesto que los datos están repartidos
en varios archivos, y estos pueden tener diferentes formatos, es difícil escribir nuevos
programas para obtener los datos apropiados.
Usuarios múltiples: Para mejorar el funcionamiento general del sistema y obtener
un tiempo de respuesta más corto, muchos sistemas son multiusuario o sea que
permiten el uso de diferentes usuarios en forma simultánea o concurrente. En un
ambiente de este tipo, las diferentes actualizaciones sobre el mismo dato pueden
resultar en dejar los datos inconsistentes. Por ejemplo: un cuentahabiente del banco
XXX tiene un saldo de $1000 y en forma simultánea el cliente hace un retiro y el
banco hace el descuento por compra de chequera. Como las dos transacciones se
hacen al mismo tiempo el dato que leen ambas transacciones es $1000. Supongamos
8

que la chequera cuesta $100 y el retiro es por $200, entonces el modulo de
descuento de chequeras escribirá el valor $900 en el archivo, y el modulo de retiros
de los clientes escribe $800, luego el saldo final será $800 que fue el ultimo datos
escrito en el archivo. Será este dato correcto?
Seguridad: el empleado de nomina debe tener acceso a los datos de los empleados
y no de los clientes, y a la vez un cajero debe tener acceso a la información de
clientes y no a la de los empleados.
Integridad: será lógico un precio de un producto que sea menor que cero? Para esto
se imponen ciertos limitantes de consistencia pero que pasara cuando resulten
nuevos limitantes?
6.2. Desventajas de las bases de datos
Complejidad: Los SGBD son conjuntos de programas que pueden llegar a ser
complejos con una gran funcionalidad. Es preciso comprender muy bien esta
funcionalidad para poder realizar un buen uso de ellos.
Coste del equipamiento adicional: Tanto el SGBD, como la propia base de datos,
pueden hacer que sea necesario adquirir más espacio de almacenamiento. Además,
para alcanzar las prestaciones deseadas, es posible que sea necesario adquirir una
máquina más grande o una máquina que se dedique solamente al SGBD. Todo esto
hará que la implantación de un sistema de bases de datos sea más cara.
Vulnerable a los fallos: El hecho de que todo esté centralizado en el SGBD hace
que el sistema sea más vulnerable ante los fallos que puedan producirse. Es por ello
que deben tenerse copias de seguridad (Backup).
Tipos de Campos: Cada Sistema de Base de Datos posee tipos de campos que
pueden ser similares o diferentes. Entre los más comunes podemos nombrar:
• Numérico: entre los diferentes tipos de campos numéricos podemos encontrar
enteros “sin decimales” y reales “decimales”.
• Booleanos: poseen dos estados: Verdadero “Si” y Falso “No”.
• Memos: son campos alfanuméricos de longitud ilimitada. Presentan el
inconveniente de no poder ser indexados.
• Fechas: almacenan fechas facilitando posteriormente su explotación. Almacenar
fechas de esta forma posibilita ordenar los registros por fechas o calcular los días
entre una fecha y otra.
• Alfanuméricos: contienen cifras y letras. Presentan una longitud limitada (255
caracteres).
9

Autoincrementables: son campos numéricos enteros que incrementan en una unidad
su valor para cada registro incorporado. Su utilidad resulta: Servir de identificador ya
que resultan exclusivos de un registro .
. Bases de datos. Obtenido en Internet el 22 agosto de 2008. Hora: 10.42 pm.
http://html.rincondelvago.com/bases-de-datos_9.html
. ¿Qué son las bases de datos. Obtenido en Internet el 22 agosto de 2008. Hora: 10.42 pm
http://www.maestrosdelweb.com/principiantes/%C2%BFque-son-las-bases-de-datos/
. Ibíd.
. Ibíd. P. 6
10

7. Abstracción de los datos
Una base de datos es en esencia una colección de archivos relacionados entre sí, de la cual
los usuarios pueden extraer información sin considerar las fronteras de los archivos. Los
niveles de abstracción son la forma de esconder la complejidad de los datos para que
usuarios no familiarizados con las computadoras puedan manipular los datos.
Existen diferentes niveles de abstracción para simplificar la interacción de los
usuarios con el sistema; Interno, conceptual y externo, específicamente el de
almacenamiento físico, el del usuario y el del programador.
7.1. Nivel físico.
Es la representación del nivel más bajo de abstracción, en éste se describe en detalle la
forma en cómo de almacenan los datos en los dispositivos de almacenamiento (por ejemplo,
mediante señaladores o índices para el acceso aleatorio a los datos).
7.2. Nivel conceptual
El siguiente nivel más alto de abstracción, describe que datos son almacenados realmente
en la base de datos y las relaciones que existen entre los mismos, describe la base de datos
completa en términos de su estructura de diseño. El nivel conceptual de abstracción lo usan
los administradores de bases de datos, quienes deben decidir qué información se va a
guardar en la base de datos.
Consta de las siguientes definiciones:
1. Definición de los datos: Se describen el tipo de datos y la longitud de campo todos los
elementos direccionales en la base. Los elementos por definir incluyen artículos elementales
(atributos), totales de datos y registros conceptuales (entidades).
2. Relaciones entre datos: Se definen las relaciones entre datos para enlazar tipos de
registros relacionados para el procesamiento de archivos múltiples.
En el nivel conceptual la base de datos aparece como una colección de registros lógicos, sin
descriptores de almacenamiento. En realidad los archivos conceptuales no existen
físicamente. La transformación de registros conceptuales a registros físicos para el
almacenamiento se lleva a cabo por el sistema y es transparente al usuario .
11

1. Nivel de visión.
Nivel más alto de abstracción, es lo que el usuario final puede visualizar del sistema
terminado, describe sólo una parte de la base de datos al usuario acreditado para verla. El
sistema puede proporcionar muchas visiones para la misma base de datos.
La interrelación entre estos tres niveles de abstracción se ilustra en la siguiente figura 1.
Figura 1
Basada en la dirección:: http://www.temas-estudio.com/base-de-datos/ Obtenida en la Fecha: agosto 17
de 2008 hora: 14.36.
Diseño: Equipo Técnico P.A.V. Agosto del 2008
. Abstracción de la información. Obtenido en Internet el 22 agosto de 2008. Hora: 10.42 pm
http://atenea.udistrital.edu.co/profesores/jdimate/basedatos1/tema1_3.htm
12

8. Sistema Manejador de Bases de
Datos – DBMS
8.1. Sistema Manejador de Bases de Datos – DBMS
Es el corazón de la base de datos ya que se encarga del control total de los posibles
aspectos que la puedan afectar. Es una colección de numerosas rutinas de software
interrelacionadas, cada una de las cuales es responsable de alguna tarea específica .
8.2. Las funciones principales de un DBMS son:
1. Crear y organizar la Base de datos.
2. Establecer y mantener las trayectorias de acceso a la base de datos de tal forma que
los datos puedan ser accesados rápidamente.
3. Manejar los datos de acuerdo a las peticiones de los usuarios.
4. Registrar el uso de las bases de datos.
5. Interacción con el manejador de archivos.
6. Respaldo y recuperación.
7. Control de concurrencia.
8. Seguridad e integridad.
El DBMS también conocido como el Gestor de Base de Datos, es como la interfase entre la
base de datos física y las peticiones del usuario. El DBMS interpreta las peticiones de
entrada/salida del usuario y las manda al sistema operativo para la transferencia de datos
entre la unidad de memoria secundaria y la memoria principal. El siguiente grafico ilustra
mejor este funcionamiento:
13

Figura 2
Basada en la dirección:: http://atenea.udistrital.edu.co/profesores/jdimate/basedatos1/tema1_9.htm Obtenida en la Fecha: agosto
17 de 2008 hora: 14.36. Diseño: Equipo Técnico P.A.V. Agosto del 2008
Algunos ejemplos de manejadores de bases de datos son: Dbase, Fox, Access, Informix,
Unify, Oracle, Internase
. Ibíd., pg. 14.
. Ibíd., pg. 14.
14

9. Lenguaje de consulta
estructurado (SQL)
9.1. Lenguaje de consulta estructurado (SQL)
Es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar
diversos tipos de operaciones sobre las mismas. SQL es considerado actualmente como un
lenguaje estándar.
Los DBMS están compuestos por el lenguaje de definición de datos y el lenguaje de
manipulación de datos
1. Lenguaje de Definición de Datos
Denominado por sus siglas como: DDL(Data definition Language), permite definir un
esquema de base de datos por medio de una serie de definiciones que se expresan en un
lenguaje especial, el resultado de estas definiciones se almacena en un archivo especial
llamado diccionario de datos.
El resultado de la compilación de las sentencias DDL es un conjunto de tablas que se
almacena en un archivo especial llamado diccionario o directorio de datos.
2. Lenguaje de Manipulación de Datos
La manipulación de datos se refiere a las operaciones de insertar, recuperar, eliminar o
modificar datos; dichas operaciones son realizadas a través del lenguaje de manipulación de
datos (DML, Data Manipulation Language), que es quién permite el acceso de los usuarios a
los datos.
Existen básicamente 2 tipos de lenguajes de manipulación de datos: Procedimentales en
los que los LMD requieren que el usuario especifique que datos se necesitan y cómo
obtenerlos y No procedimentales, donde los LMD requieren que el usuario especifique que
datos se necesitan y sin especificar cómo obtenerlos.
15

10.Estructura General del Sistema
10.1. Estructura General del Sistema
Un sistema de base de datos se encuentra dividido en módulos cada uno de los cuales
controla una parte de la responsabilidad total de sistema. En la mayoría de los casos, el
sistema operativo proporciona únicamente los servicios más básicos y el sistema de la base
de datos debe partir de esa base y controlar además el manejo correcto de los datos. Así el
diseño de un sistema de base de datos debe incluir la interfaz entre el sistema de base de
datos y el sistema operativo.
Los componentes funcionales de un sistema de base de datos, son:
1. Gestor de archivos: Gestiona la asignación de espacio en la memoria del disco y de
las estructuras de datos usadas para representar información.
2. Manejador de base de datos: Sirve de interfaz entre los datos y los programas de
aplicación.
3. Procesador de consultas: Traduce las proposiciones en lenguajes de consulta a
instrucciones de bajo nivel. Además convierte la solicitud del usuario en una forma
más eficiente.
4. Compilador de DDL: Convierte las proposiciones DDL en un conjunto de tablas que
contienen metadatos, estas se almacenan en el diccionario de datos.
5. Archivo de datos: En él se encuentran almacenados físicamente los datos de una
organización.
6. Diccionario de datos: Contiene la información referente a la estructura de la base
de datos.
7. Índices: Permiten un rápido acceso a registros que contienen valores
específicos.
Una forma gráfica de representar los componentes antes mencionados y la relación que
existe entre ellos sería la siguiente.
16

Figura 3
Estructura Global del Sistema
Basada en la dirección: http://atenea.udistrital.edu.co/profesores/jdimate/basedatos1/tema1_12.htm
Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Diseño: Equipo Técnico P.A.V. Agosto del 2008
17

11.Modelo de datos
Un Modelo es una representación de la realidad que contiene las características generales de
algo que se va a realizar. En base de datos, esta representación la elaboramos de forma
gráfica. Un Modelo de Datos es una colección de herramientas conceptuales para describir
los datos, las relaciones que existen entre ellos, semántica asociada a los datos y
restricciones de consistencia.
Los modelos de datos se dividen en tres grupos:
Modelos lógicos basados en objetos.
Modelos lógicos basados en registros.
Modelos físicos de datos.
11.1. Modelos lógicos basados en objetos
Se usan para describir datos en los niveles conceptual y de visión, es decir, con este modelo
representamos los datos de tal forma como nosotros los captamos en el mundo real, tienen
una capacidad de estructuración bastante flexible y permiten especificar restricciones de
datos explícitamente. Existen diferentes modelos de este tipo como el entidad relación y el
orientado a objetos, pero el más utilizado por su sencillez y eficiencia es el modelo Entidad-
Relación.
El Modelo Entidad-Relación: Denominado por sus siglas como: E-R; Este modelo representa
a la realidad a través de entidades, que son objetos que existen y que se distinguen de otros
por sus características, por ejemplo: un alumno se distingue de otro por sus características
particulares como lo es el nombre, o el numero de control asignado al entrar a una
institución educativa, así mismo, un empleado, una materia, etc.
11.2. Modelos lógicos basados en registros
Se utilizan para describir datos en los niveles conceptual y físico.
Estos modelos utilizan registros e instancias para representar la realidad, así como las
relaciones que existen entre estos registros (ligas) o apuntadores. A diferencia de los
modelos de datos basados en objetos, se usan para especificar la estructura lógica global de
la base de datos y para proporcionar una descripción a nivel más alto de la implementación.
Los tres modelos de datos más ampliamente aceptados son:
18

Modelo jerárquico: Es similar al modelo de red en cuanto a las relaciones y datos,
ya que estos se representan por medio de registros y sus ligas. La diferencia radica
en que están organizados por conjuntos de árboles en lugar de gráficas arbitrarias.
Figura 4
Modelo Jerárquico de Bases de Datos
Basada en la dirección:
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060029/lecciones/cap1-6.html
Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36. Diseño: Equipo Técnico P.A.V. Agosto del 2008
19

Modelo de Red: Este modelo representa los datos mediante colecciones de registros
y sus relaciones se representan por medio de ligas o enlaces, los cuales pueden verse
como punteros. Los registros se organizan en un conjunto de gráficas arbitrarias. Un
modelo jerárquico presenta una estructura como la que se muestra en la figura 5.
Figura 5
Ejemplo Modelo Jerárquico
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060029/lecciones/cap1-6.html Obtenida en la Fecha:
agosto 17 de 2008 hora: 14.36. Diseño: Equipo Técnico P.A.V. Agosto del 2008
Modelo Relacional: En este modelo se representan los datos y las relaciones entre
estos, a través de una colección de tablas, en las cuales los renglones (tuplas)
equivalen a los cada uno de los registros que contendrá la base de datos y las
columnas corresponden a las características (atributos) de cada registro localizado en
la tupla. Es el tipo de base de datos más difundido y utilizado en la actualidad y el
cual veremos en detalle en el segundo encuentro. Un modelo de datos relacional,
presenta una estructura como la que se muestra en la figura 6.
20

Figura 6
Ejemplo del Modelo Relacional
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060029/lecciones/cap1-6.html
Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36. Diseño: Equipo Técnico P.A.V. Agosto del 2008
Modelos físicos de datos: Se usan para describir a los datos en el nivel más bajo,
aunque existen muy pocos modelos de este tipo, básicamente capturan aspectos de
la implementación de los sistemas de base de datos. Existen dos clasificaciones de
este tipo que son:
Modelo unificador
Memoria de elementos .
. Ibid., p 23
. Ibíd., pg. 23
. Modelos de datos. Obtenida en Internet el 22 agosto de 2008. Hora: 10.42 pm
http://atenea.udistrital.edu.co/profesores/jdimate/basedatos1/tema1_4.htm
21

12. Ciclo de vida de una base de
datos
Bases de datos-Modelo de datos-Ciclo de vida
El ciclo de vida de un desarrollo de una base de datos consta de siete pasos:
1. Análisis de las necesidades
2. Estudio de viabilidad
3. Definición de requisitos
4. Diseño conceptual / lógico
5. Implementación
6. Evaluación y Mantenimiento
12.1. Análisis de las necesidades
En reunión con el cliente se deben documentar los tres grupos de usuarios definidos en la
introducción de la guía, las necesidades de información de cada uno de ellos, así como los
informes que cada uno necesita para su actividad y el contenido de los mismos. Cuanta más
precisión exista en estos requisitos iniciales más preciso será el desarrollo de la base de
datos.
En esta reunión también debe quedar documentados los niveles de seguridad de los grupos
de usuarios, los derechos de cada uno de ellos sobre los datos, los requisitos de los sistemas
informáticos del cliente (sistema operativo, tipo de red, servidores, etc.) y la ubicación de
los usuarios.
No hay que olvidar que normalmente en las empresas existen ya sistemas de
almacenamiento de datos, por tanto es conveniente analizar los datos ya existentes y
analizar las posibles relaciones con la base de datos a desarrollar.
Un cuestionario muy sencillo pero muy útil para el administrador es el siguiente (a rellenar
por todos los usuarios):
Nombre
Cargo
Área de Responsabilidad
Obligaciones principales que requieren información de la base datos
¿De qué aplicaciones recibe información?
¿Con cuánta frecuencia recibe información?
¿Qué hace con esta información?
¿Qué precauciones de seguridad debe tomar con respecto a la información?
¿Para qué aplicación proporciona datos?
22

¿Están contemplados cambios para alguna de sus actividades actuales que involucren
alguna de las informaciones anteriores?
12.2. Estudio de viabilidad
Un estudio de viabilidad implica la preparación de un informe con las características
siguientes:
1. Viabilidad tecnológica. ¿Hay tecnología suficiente para el desarrollo?
2. Viabilidad operacional. ¿Existen suficientes recursos humanos, presupuesto, experiencia y
formación para el desarrollo?
3. Viabilidad económica. ¿Se pueden identificar los beneficios? ¿Los beneficios costearían el
desarrollo del sistema? ¿Se pueden medir los costes y los beneficios?
12.3. Definición de requisitos
Los requisitos de desarrollo involucran el software y hardware necesario para la
implementación, los recursos humanos necesarios (tanto internos como externos), la
formación al personal.
Aunque un poco al margen del tema es conveniente parar en este momento y planificar las
acciones a realizar elaborando un cronograma del proyecto y un organigrama con las
responsabilidades de cada miembro del equipo. Conviene señalar quienes van a ser los
interlocutores y fijar un calendario de reuniones de seguimiento del proyecto.
Hay que definir la figura del validador, esta persona será la encargada de velar en cada
momento que no se está rebasando el alcance del proyecto, así como asegurar que la
implementación está encaminada a subsanar las necesidades del cliente.
12.4. Diseño
En esta etapa se crea un esquema conceptual de la base de datos. Se desarrollan las
especificaciones hasta el punto en que puede comenzar la implementación. Durante esta
etapa se crean modelos detallados de las vistas de usuario y sobre todo las relaciones entre
cada elemento del sistema, documentando los derechos de uso y manipulación de los
diferentes grupos de usuarios.
23

24
Si parte de la información necesaria para crear algún elemento establecido ya se encuentra
implementado en otro sistema de almacenamiento hay que documentar que relación existirá
entre uno y otro y detallar los sistemas que eviten la duplicidad o incoherencia de los datos.
El diseño consta, como se vio anteriormente, de tres fases: el diseño global o conceptual, el
diseño lógico y el modelo físico.
12.5. Implementación
Una vez totalmente detallado el modelo conceptual se comienza con la implementación física
del modelo de datos, a medida que se va avanzando en el modelo el administrador del
sistema va asegurando la corrección del modelo y el validador la utilidad del mismo.
La implementación consiste en el desarrollo de las tablas, los índices de los mismos, las
condiciones de validación de los datos, la relación entre las diferentes tablas. Por otro lado,
la definición de las consultas y los parámetros a utilizar por cada una de ellas.
Una vez finalizada la implementación física, se asignan las correspondientes medidas de
seguridad y se ubica la base de datos en el lugar correspondiente.
12.6. Evaluación y Perfeccionamiento
En esta última etapa todos los usuarios del sistema acceden a la base de datos y deben
asegurarse el correcto funcionamiento de la misma, que sus derechos son los adecuados,
teniendo a su disposición cuanta información necesiten. También deberán asegurarse que el
acceso a los datos es cómodo, práctico, seguro y que se han eliminado, en la medida de lo
posible, las posibilidades de error.
El administrador se asegura que todos los derechos y todas las restricciones han sido
implementadas correctamente y que se ha seguido en Tutorial de estilo en la totalidad de la
implementación.
El validador se asegurará que todas las necesidades del cliente han sido satisfechas.
El contenido del tema 12: Ciclo de Vida de una base de datos ha sido íntegramente elaborado por
Claudio Casares www.lobocom.es/~claudio
Tomado de http://www.solorecursos.com/manuales/sql/moddat003.htm. Septiembre 20 de 2008.

Unidad 2
Modelo Entidad
Relación (E/R)
El diseño conceptual es el proceso por el cual se construye un modelo
de la información que se utiliza en una empresa u organización, el
objetivo más esencial de la fase de requerimientos es crear un modelo
de los datos del usuario. Tal modelo identifica las cosas que se van a
almacenar en la base de datos y define sus estructuras y las relaciones,
es el modelo entidad relación uno de los modelos más conocidos,
simples y claros donde se puede expresar gráficamente toda la
estructura de la base de datos.

1. Modelo Entidad Relación
Definición: Es la percepción del mundo real. Colección de objetos básicos llamados entidades
y relaciones. El modelo contiene ciertas restricciones a la que debe de ajustarse los datos.
Lo que hace al modelo entidad relación universal es que no está enfocado al diseño de un
modelo de bases de datos particular.
Se emplea para interpretar, especificar y documentar los requerimientos para un sistema de
bases de datos ya que proporciona estructuras que muestran el diseño general de los
requerimientos de datos de los usuarios.
El modelo debe estar compuesto por:
Entidades
Atributos
Relaciones
Cardinalidad
Claves
26

2. Ventajas del modelo entidad
relación
Constituye la base del modelo conceptual de datos.
Es el modelo semántico más popular encontrado en los libros..
Proporciona estructuras que muestran el diseño general de los requerimientos de datos
de los usuarios.
Va de lo particular a lo general
Es muy flexible está enfocado al diseño de muchas situaciones.
27

3. Pasos Para Construir El Modelo
Entidad Relación
Identificación de entidades.
Identificación de relaciones.
Elaborar el modelo.
Identificar atributos.
Refinar modelo.
Pasar el modelo entidad relación a un modelo implementable (modelo
relacional).
3.1. Primer Paso: Reconocer Entidades
Es toda cosa u objeto significativo (real ó imaginario) del cual se requiere conocer ó
almacenar información.
3.1.1. REPRESENTACIÓN DE ENTIDADES
Toda entidad se representa por medio de un rectángulo con el nombre de la entidad dentro
del rectángulo en mayúsculas.
Ejemplo
3.1.2. Cómo Identificar Las Entidades
Es el paso central del proceso de modelo entidad relación. Los diversos tipos de entidades
son:
PERSONAS: Jurídicas o naturales como: cliente, alumno, vendedor, profesor,
empleado etc.
OBJETOS: Tangibles y no tangibles como: artículo, cuenta etc.
LUGARES: Bodega, ciudad, aula.
TRANSACCIONES: Compra, venta, evaluación.
CONCEPTOS O ABSTRACCIONES: Tipo crédito, Tipo servicio, Tipo cliente
etc.
28

Toda persona realiza una transacción y que la acción de esta recae siempre sobre un
objeto dado.
Todas las personas y los objetos residen y se almacenan en un lugar
3.2. Segundo Paso: Relaciones O Reglas
Relación: Es una asociación nómbrale, significativa y estable entre dos entidades.
Ejemplo
Se tienen dos entidades estudiante, clase. La relación entre estudiante y clase es:
Cada estudiante debe tener una ó más clases y cada clase debe de estar compuesta por uno
ó más estudiantes.
3.2.1. Representación De Las Relaciones O Reglas
Toda relación tiene dos extremos y para cada uno de los cuales existen:
1. Una leyenda: generalmente es un verbo.
• Un grado de cardinalidad
29

1:1 uno a uno
Ejemplo tomado de: http://labredes.itcolima.edu.mx/fundamentosbd/sd_u2_2.htm.
Fecha Septiembre 27 de 2008 hora: 10 pm. Diseño: Equipo Técnico P.A.V
1:N uno a muchos
Tomado de: http://labredes.itcolima.edu.mx/fundamentosbd/sd_u2_2.htm. Fecha
Septiembre 27 de 2008 hora: 10 pm. Diseño: Equipo Técnico P.A.V
30

N:M muchos a muchos
Ejemplo tomado de:
http://labredes.itcolima.edu.mx/fundamentosbd/sd_u2_2.htm. Fecha Septiembre
27 de 2008 hora: 10 pm. Diseño: Equipo Técnico P.A.V
3.2.2. Cardinalidad o multiplicidad de las relaciones:
Imagen basada en: http://gemini.udistrital.edu.co/comunidad/profesores/rfranco/modelo_er.htm Fecha agosto 14 de 2008 hora:
10 pm. Diseño: Equipo Técnico P.A.V
31

32
3.2.3. Una condición opcional ó mandatoria
Mandatoria: Se representa con línea continua y se utiliza la palabra
debe_____________________Toma desde 1, 2, .., N
Opcional: Se representa con línea discontinua y se utiliza la palabra puede_ _ _ _ _
_ _ _ _ _ _ _ Toma desde 0, 1, 2,..,N
Al hacer la unión de estas dos partes de la relación queda:
La relación ó regla se escribe de la siguiente forma:
Cada estudiante debe inscribirse en uno ó más club Y cada club puede tener uno ó más
estudiantes.
Imagen basada en: http://gemini.udistrital.edu.co/comunidad/profesores/rfranco/modelo_er.htm Fecha agosto 14 de 2008
hora: 10 pm. Diseño: Equipo Técnico P.A.V

3.2.4. RELACIONES RECURSIVAS
Es una jerarquía definida sobre una misma entidad.
Para este tipo de relaciones también se tiene en cuenta las reglas anteriores como:
La leyenda, la cardinalidad y la condición.
3.2.5. La regla ó relación se escribe:
Cada cliente puede recomendar uno y solo un cliente y cada cliente puede ser
recomendado por uno y solo un cliente.
3.3. Tercer Paso: Elaborar El Modelo
Para elaborar el modelo entidad relación se tienen en cuenta las entidades que tengo
relacionadas sin repetir entidades.
Ejemplos:
33

Imagen basada en: http://gemini.udistrital.edu.co/comunidad/profesores/rfranco/modelo_er.htm Fecha agosto 14 de 2008 hora: 10
pm. Diseño: Equipo Técnico P.A.V
34

3.4. Cuarto Paso: Reconocer Atributos
Cualquier detalle que sirve para identificar, describir, cualificar, clasificar ó expresar el
estado de una entidad. Un atributo puede ser: Texto, número, figuras ó sonidos.
3.4.1. TIPOS DE ATRIBUTOS
Atributos clave primaria: Toda entidad debe ser identificada con unicidad mediante uno de
sus atributos ó una combinación de los mismos, denominado clave primaria ó identificador
único.
Así todos los atributos de una entidad deben depender únicamente del valor de la clave
primaria. Su representación para el modelo entidad relación se hace colocando el símbolo #
antepuesto al nombre del atributo.
Ejemplo:
Atributos mandatarios u obligatorios: Cuando el valor de un atributo debe ser siempre
conocido, este se representa mediante un símbolo * antepuesto al nombre del atributo.
Ejemplo
35

Atributos opcionales: Son aquellos que pueden ser desconocidos, estos se representan por
punto antepuesto al nombre del atributo.
Ejemplo
3.4.2. Reglas Para La Identificación De Atributos
Durante este proceso es posible identificar nuevas entidades y relaciones ocultas en el
modelo.
1. Toda entidad debe tener un identificador único ó clave primaria en caso de que no la
tenga puede asignar una.
2. Un atributo debe escribirse siempre en singular y en minúscula, un nombre de
atributo en plural coincide con el problema de repetición esta repetición de atributos
puede revelar la existencia de entidades faltantes en el modelo.
Ejemplo:
Aquí podemos ver que un cliente puede tener varios teléfonos lo que me está indicando la
presencia de una nueva entidad llamada teléfono.
Ejemplo:
36

3. Un atributo se transforma en una entidad cuando tiene significado completo en sí
mismo, con relaciones y atributos propios.
Podemos observar que área que es un atributo y este también tiene atributos propios como
número del área y nombre del área y se pude relacionar con la materia.
Toda entidad debe tener al menos dos atributos una clave primaria y un descriptor. Las
únicas entidades que pueden tener solo la clave primaria son las entidades de intersección
que tienen clave primaria compuesta por dos atributos
37

3.4.3. Como Identificar Claves:
Clave candidatas: Es un grupo de atributos que identifican de forma única un
registro en una tabla.
Clave primaria: Es una de las claves candidatas que se selecciona para que sea
clave primaria.
Clave secundaria ó alterna: Es la clave que queda después de escoger la clave
primaria.
Clave compuesta: Es una clave con más de un atributo, es el caso de las entidades
de intersección.
Clave sustituta: Es una columna de valores únicos que puede mantener una
aplicación ó el DBMS.
Clave Ajena: Es un atributo que es una clave primaria en una entidad y que está en
otras entidades fuera de aquella a donde pertenece, estas clave son muy importantes
ya que por medio de estas hace la relación el modelo relacional
3.5. Quinto Paso: Refinar Modelo
Para refinar el modelo entidad relación:
1. Se destruye toda relación N:M que tenga el modelo para que quede 1:N.
3.5.1. COMO ELIMINAR LAS RELACIONES DE N:M
Se crea una nueva entidad que intersecta a las entidades participantes y donde el
identificador único (clave primaria) se forma mediante la combinación de las claves
primarias de dichas entidades.
Esta es la relación que debo eliminar para que queden relaciones 1:N
38

La relación queda de la siguiente manera:
Las entidades estudiante y club son las entidades participantes y la entidad est_club es la
entidad de intersección ó entidad débil y toda la relación se llama relación de dependencia.
La entidad de intersección puede tener únicamente la clave primaria como se dijo en el
reconocimiento de claves y en caso de colocarle otros atributos hay que tener en cuenta que
este dependa de los dos atributos que forman la clave primaria.
Ejemplo:
Un atributo para la entidad EST_CLUB sería el horario en que un estudiante está inscrito en
un club.
3.5.2. Reglas para ubicar la clave foráneas:
1. Si la relación es de 1: 1 cualquiera de las dos entidades le pasa la clave primaria a la
otra
2. Si la relación es de 1: N: la entidad lado 1 le pasa la clave primaria al
lado N
• Otros puntos importantes para tener en cuenta al momento de refinar el modelo
Revisar para ver que hace falta ó que es redundante en el modelo acuerdo a las
condiciones o requerimientos que se pidieron.
39

4. Otros conceptos para el modelo
entidad relación
4.1. SUPERCLASES Y SUBCLASES DE ENTIDADES
En el modelo entidad relación, una entidad agrupa un conjunto de ocurrencias de entidad del
mismo tipo. En muchos casos, estas ocurrencias se pueden agrupar a su vez en otros
subconjuntos que tienen un significado propio para los propósitos de la Base de Datos y, por
tanto, deberían representarse de forma explícita. Por ejemplo, la entidad EMPLEADO puede
a su vez subdividirse en SECRETARIA, INGENIERO, JEFE, TÉCNICO, ASALARIADO,
SUBCONTRATADO, etc. El conjunto de ocurrencias de entidad en cada una de estas
entidades será un subconjunto de las ocurrencias de entidad de EMPLEADO, ya que por
ejemplo, un ingeniero también es un empleado. Llamaremos a cada uno de estos
subconjuntos Subclases de la entidad EMPLEADO y a EMPLEADO una Superclase de cada
uno de estos subconjuntos.
Llamaremos a la relación existente entre las Superclases y las Subclases como relación
Clase/Subclase. En el ejemplo anterior, EMPLEADO/SECRETARIA y EMPLEADO/TÉCNICO son
dos relaciones Clase/Subclase. Hay que tener en cuenta que una ocurrencia de una Subclase
representa el mismo objeto real que alguna correspondiente a su Superclase, por ejemplo la
SECRETARIA "Concha Leco" será también la EMPLEADO "Concha Leco". Por tanto, la
ocurrencia de Subclase es la misma que en la Superclase pero con un rol específico. Una
ocurrencia de Subclase no tienen sentido si no es a su vez ocurrencia de Superclase. Por
otro lado, una ocurrencia de superclase puede ser a su vez ocurrencia de varias subclases o
de ninguna. Por ejemplo, "Roberto Mate" como ocurrencia de EMPLEADO puede a su vez
pertenecer a subclases INGENIERO y ASALARIADO.
4.2. HERENCIA DE ATRIBUTOS EN LA RELACIÓN
CLASE/SUBCLASE.
Debido a que una subclase es a su vez parte se una superclase, la subclase tendrá sus
atributos específicos así como los atributos correspondientes a la superclase a la que
pertenece. Esto quiere decir que la ocurrencia de entidad de una subclase hereda los
atributos correspondientes a la superclase a la que pertenece. De la misma manera hereda
las relaciones en las que su correspondiente superclase participa.
40

4.3. ESPECIALIZACIÓN.
El proceso por el que se definen las diferentes subclases de una superclase se conoce como
especialización. El conjunto de subclases se define basándonos en características
diferenciadores de las ocurrencias de entidad de la superclase. Por ejemplo, el conjunto se
subclases {SECRETARIA, INGENIERO, TÉCNICO} es una especialización de la superclase
EMPLEADO mediante la distinción del tipo de trabajo en cada ocurrencia de entidad.
Podemos tener varias especializaciones de una misma entidad basándonos en distintos
criterios. Por ejemplo, otra especialización de EMPLEADO podría dar lugar a las subclases
ASALARIADO y SUBCONTRATADO, dependiendo del tipo de contrato.
DIAGRAMAS ENTIDAD RELACIÓN
http://www.galeon.com/konnan2001/ERE.htm
Ibíd.
Ibíd.
Ibíd., p. 18
41

5. Ejercicios resueltos de modelo
entidad relación
Deseamos diseñar una base de datos para una universidad, se dispone de la siguiente
información:
Los departamentos pueden estar en una sola facultad.
Un profesor está siempre asignado a un sólo departamento y adscrito a una o varias
cátedras, pudiendo cambiar de cátedra pero no de departamento; interesa la fecha en
que un profesor es adscrito a una cátedra.
Tenga en cuenta que una cátedra puede ser asignada a varios profesores
2. Se desea diseñar una base de datos que contenga información relativa a las
carreteras de determinado país. Se pide realizar el diseño en el modelo E/R,
sabiendo que:
En dicho país las carreteras se encuentran dividas en tramos.
Un tramo siempre pertenece a una única carretera y no puede cambiar de carretera.
Un tramo puede pasar por varios términos municipales, siendo de interés el kilómetro
del tramo por el que entra en dicho término municipal y el kilómetro por el que sale.
Existen una serie de áreas en las que se agrupan los tramos y cada uno de ellos no
puede pertenecer a más de un área.
42

3. Se desea diseñar una base de datos sobre la información de las reservas de una
empresa dedicada al alquiler de automóviles. Se dispone de la siguiente información:
Un determinado cliente puede tener en un momento dado varias reservas.
Una reserva la realiza un único cliente, pero puede involucrar a varios coches.
Es importante registrar la fecha de comienzo de la reserva y la de terminación.
Todo coche tiene siempre asignado un determinado garaje, que no puede cambiar.
Cada reserva se realiza en una determinada agencia.
En la base de datos pueden existir clientes que no hayan hecho ninguna reserva.
43

4. Video club: En una tienda de video se necesita mantener información de alrededor
de 3000 casetas cada uno de los casetes tiene asignado un número por cada película
se necesita conocer un titulo y categoría por ejemplo: comedia, suspenso, drama,
acción, ciencia ficción, etc. Se mantienen algunas copias de muchas películas. Se le
da a cada película una identificación y se mantiene seguimiento de lo que contiene
cada casete.
Un casete puede venir en varios formatos y una película es grabada en un solo
casete; frecuentemente las películas son pedidas de acuerdo a un actor especifico
Tom Cruise y Demi More son los más populares es por esto que se debe mantener
información de los actores que pertenecen a cada película.
No en todas las películas actúan artistas famosos, a los clientes de la tienda le gusta
conocer datos como el nombre real del actor, y su fecha de nacimiento.
En la tienda se mantienen información solo d los actores que aparecen en las
películas y que se tiene a disposición. Solo se alquila videos a aquellos que
pertenecen al club de videos. Para pertenecer al club se debe tener un buen crédito.
Por cada miembro del club se mantiene una ficha con su nombre, teléfono y
dirección, cada miembro del club tiene asignado un número de membresía. Se desea
mantener información de todos los casetes que un cliente alquila, cuando un cliente
alquila un casete se debería conocer el nombre de la película, la fecha en la que se
alquila y la fecha de devolución.
44

ENTIDAD
CLIENTE
PELÍCULAS
TIPO_PEL
ACTORES
CASETE
ALQUILER
Ejemplo tomado de:
http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml
Fecha Septiembre 27 de 2008 hora: 10 pm
Diseño esquema: Equipo Técnico P.A.V.
45

5. Un modelo ER de Propietarios de Taxis Conductores y Empresas
• ¿Un Taxi cuantos propietarios tiene?
R/ uno (El uno se pone en PROPIETARIOS)
• ¿Un Propietario cuantos Taxis tiene?
R/ Varios (La N se pone en TAXIS)
¿Un taxi cuantos Conductores tiene?
R/ Uno (el 1 se pone en CONDUCTORES)
• ¿Un conductor Cuantos taxis maneja?
R/ Uno (El Uno se pone En TAXIS)
• ¿Un PROPIETARIO a cuantas EMPRESAS está afiliado?
R/ Varias (La N se pone en EMPRESAS)
• ¿Una empresa cuantos propietarios tiene afiliados?
R/ Varias (La N se pone en Propietarios)
46

Ejemplo tomado de:
http://www.calasanz-pereira.edu.co/prueba/html/modules/Access/normalizacion.htm. Fecha Septiembre 27 de 2008 hora: 10 pm
. Diseño esquema: Equipo Técnico P.A.V.
Nota: Este modelo no tiene destruidas las relaciones N:M. que hay entre cassette y alquiler
y la de actor películas
47

Unidad 3
Modelo
Relacional
El modelo relacional es un modelo lógico basado en registros que vino
después de que los modelos jerárquico y de red estuvieran en uso. Este
modelo relacional, no se puede decir que sea en sí un modelo
semántico de datos. Su enorme éxito no se debe a que permite de
forma implícita operaciones conceptualmente abstractas sobre los
datos, sino a los altos niveles de fiabilidad e integridad que aporta en el
manejo de grandes cantidades de datos.

1. Definición
El modelo de datos relacional fue introducido por Edgar F. Codd (1970). Se basa en una
estructura de datos simple y uniforme la relación y tiene fundamentos teóricos sólidos
El modelo relacional representa la base de datos como una colección de relaciones. En
términos mínimos informales, cada relación semeja una tabla o, hasta cierto punto, un
archivo simple.
Codd daba 12 reglas que debe cumplir cualquier base de datos que desee considerarse
relacional:
1.1. Las Doce Reglas De Codd
1. Regla de información:
Todos los datos de una base de datos relacional se representan explícitamente (al nivel
lógico) como valores de tablas.
2. Reglas de acceso garantizado:
Todos y cada uno de los datos (valor indisoluble, único o atómico) de una base de datos
relacional se garantiza que sean lógicamente accesible recurriendo a una combinación de
nombres de tabla, valor de clave primaria y nombre de columna.
3. Tratamiento sistemático de valores Nulos:
Los valores nulos (distinto de cadena de caracteres vacías o de una cadena de caracteres en
blanco y distinta de cero o de cualquier otro número) se soporta en los SGBD
completamente relacionales para representar la falta de información y la información
inaplicable de un modo sistemático e independiente del tipo de datos.
4. Catálogo en línea dinámico basado en el modelo relacional:
La descripción de la base de datos o Catalogo se representa (o almacena) a nivel lógico
como valores en tablas, del mismo modo que los datos ordinarios, de modo que los usuarios
autorizados pueden aplicar a los datos regulares.
5. Regla de sublenguaje completo de datos:
un sistema relacional puede soportar varios lenguajes de manipulación de datos (DMI) y
varios modos de uso terminal (por ejemplo, el modo de rellenar con blancos), sin embargo
49

debe haber al menos un lenguaje cuyas sentencias sean expresables, mediante alguna
sintaxis bien definida, como cadenas de caracteres, y que sea completa en cuanto al soporte
de todos los puntos siguientes:
Definición de datos y Definición de vistas
Manipulación de datos (interactiva y por programa)
Restricciones de integridad
Autorización
Fronteras de transacciones (comienzo, complementación y vuelta atrás)
6. Regla de actualización de vistas:
Todas las vistas que puedan utilizarse son también actualizables por el sistema.
7. Inserción, Modificación y Borrado de alto nivel:
Un SGBDR debe hacer más que recuperar conjuntos relacionales de datos, también debe ser
capaz de insertar, actualizar y eliminar datos como un conjunto relacional.
8. Independencia física de los datos:
Los datos deben ser físicamente independiente de los programas de aplicación. Los
programas de aplicación y las actividades terminales permanecen lógicamente inalterados
cualquiera que sean los cambios efectuados ya sea las representaciones de almacenamiento
o a los métodos de acceso.
9. Independencia lógica de los datos:
Cada vez que sea posible, el Software de aplicación debe ser independiente de los cambios
hechos a las tablas Base. Los programas de aplicación y las actividades terminales
permanecen lógicamente inalterados cuando se efectúan sobre las tablas de base de
cambios preservadores de la información de cualquier tipo que teóricamente permita
alteraciones.
10. Independencia de integridad:
La integridad de los datos debe ser definible en el lenguaje relacional y almacenarse en el
Catálogo. Las restricciones de integridad específicas para una base de datos relacional y
almacenables en el catálogo, no en los programas de aplicación.
11. Regla de no subversión:
Si un sistema relacional tiene un lenguaje de bajo nivel (un solo registro cada vez), ese bajo
nivel no puede ser utilizado para subvertir o suprimir las reglas de integridad y las
restricciones expresadas en el lenguaje relacional de nivel superior (múltiples registros a la
vez)
50

12. Un sistema de bases de datos relacionla(SGBDR) tiene independencia
distributiva.
1. Las 12 reglas de Codd. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm.
http://www.atpsoftware.net/Public/Articulos.php
51

2. Estructura Del Modelo Relacional
La definición de relación desde el punto de vista matemático es: Una relación es un
subconjunto de un producto cartesiano de un listado de dominios.
El producto cartesiano son todas las combinaciones posibles entre conjuntos.
Ejemplo: Dados los conjuntos A y B, donde:
Esquema diseñado por: Equipo Técnico P.A.V. Octubre del 2008
Esta relación es un subconjunto del producto cartesiano.
Ejemplo de una relación o tabla de una BD relacional:
52

Para cada atributo existe un conjunto de valores permitidos llamado dominio de ese
atributo.
Los dominios corresponden a los tipos de datos primitivos de los lenguajes de programación.
Cada fila representa una tupla y una tupla es un conjunto ordenado de valores (atributos).
Por tanto una relación es un conjunto de tuplas filas o registros. Cada atributo, columna o
campo sólo puede tomar un único valor del dominio.
El grado de una tabla = número de columnas
La cardinalidad = número de registros
Debido a que las tablas son básicamente relaciones se utilizan los términos matemáticos
relación y tupla en lugar de los de tabla y fila.
Cuando se habla de una BD debe diferenciarse entre el esquema de la BD, es decir, el
diseño lógico de la BD y una instancia de la BD que está constituida con la información
contenida en la BD en un momento determinado.
El esquema de una relación es en general una lista de atributos y sus correspondientes
dominios; la notación para ello sería:
Producto= (cod_prd: string, nom_prd: string, valor: numérico)
Sin embargo, no es necesario hacer una definición precisa del dominio de cada atributo, sino
hasta el momento de la implementación. Por tanto la notación puede ser:
Producto= (cod_prd, nom_prd, valor)
El esquema de la BD en este modelo, es el conjunto de definiciones de sus esquemas.
Ejemplo: Para una empresa productora de partes, supondremos el siguiente conjunto de
esquemas de relaciones:
53

Parte= (nro_pte, nom_pte, color, peso, ciudad)
Proveedor= (nro_prv, nom_prv, ciudad_prv)
Suministro= ( nro_prv,nro_pte,cantidad_sum)
La característica fundamental de este modelo de datos es que las asociaciones entre tuplas
(entidades) se representan únicamente por valores de datos en columnas, sacados de un
dominio común.
Ejemplo: La asociación entre PROVEEDOR y SUMINISTRO se da por el campo nro_prv
que debe ser igual en ambas relaciones cuando se refieren a un PROVEEDOR determinado.
54

3. Transformación Del Modelo E-R
En Tablas Relacionales
Si la BD se ajusta a un diagrama E-R, estas son las reglas de transformación:
1. Las entidades se representan en tablas (relaciones) y los atributos en columnas.
2. Las asociaciones 1:N se representan replicando la llave primaria de la tabla del lado
1, como columna externa en la tabla del lado muchos. A esta columna se le
denomina llave foránea.
3. Las asociaciones 1:1 se representan replicando la llave primaria en una de las dos
tablas como columna externa de la otra.
4. Las asociaciones M:N deben resolverse generando una tercera entidad denominada
de intersección la cual tendrá como llave primaria la combinación de las llaves
primarias de las entidades que intersecta, mas los atributos resultantes de la
asociación, si existen. Las asociaciones 1:M resultantes se resuelven de acuerdo con
la regla de representación de entidades (es decir, en tablas independientes).
Esquema diseñado por: Equipo Técnico P.A.V. Octubre del 2008
55

4. Reglas De Integridad (RI)
Los datos contenidos en la base de datos deben ser correctos confiables y
consistentes.
Las RI se pueden ser:
1. Semánticas:
En el mundo real existen ciertas restricciones que deben cumplir los elementos en él
existentes; por ejemplo, una persona sólo puede tener un número de DNI y una única
dirección oficial. Cuando se diseña una base de datos se debe reflejar fielmente el universo
del discurso que estamos tratando, lo que es lo mismo, reflejar las restricciones existentes
en el mundo real.
Tienen que ser definidas por los diseñadores en el modelo entidad relación.
2. Reglas de negocio
Los usuarios o los administradores de la base de datos pueden imponer ciertas restricciones
específicas sobre los datos, denominadas reglas de negocio.
Por ejemplo, si en una oficina de la empresa inmobiliaria sólo puede haber hasta veinte
empleados, el SGBD debe dar la posibilidad al usuario de definir una regla al respecto y debe
hacerla respetar. En este caso, no debería permitir dar de alta un empleado en una oficina
que ya tiene los veinte permitidos.
Integridad de dominio: restringimos los valores que puede tomar un atributo respecto a su
dominio, por ejemplo EDAD >= 18 and EDAD<= 65. Una nota>=0 and nota<=5
3. Reglas de la entidad
Tipos de datos: Al momento de definir la tabla se deben definir correctamente
los tipos de datos de los atributos o columnas.
Permitir valores NULL
La nulabilidad de una columna determina si las filas de una tabla pueden contener un valor
NULL en esa columna. Un valor NULL no es lo mismo que cero (0), en blanco o que una
cadena de caracteres de longitud cero, como "". NULL significa que no hay ninguna entrada.
La presencia de un valor NULL suele implicar que el valor es desconocido o no está definido.
Por ejemplo, un valor NULL en la columna fecha_venta de la tabla Producto no implica que
el artículo no tenga una fecha de venta final. El valor NULL significa que se desconoce la
fecha o que no se ha establecido.
56

Restricciones UNIQUE
Puede utilizar restricciones UNIQUE para garantizar que no se escriben valores duplicados en
columnas específicas que no forman parte de una clave principal. Tanto la restricción
UNIQUE como la restricción PRIMARY KEY exigen la unicidad; sin embargo, debe utilizar la
restricción UNIQUE y no PRIMARY KEY si desea exigir la unicidad de una columna o una
combinación de columnas que no forman la clave principal.
En una tabla se pueden definir varias restricciones UNIQUE, pero sólo una restricción
PRIMARY KEY.
Además, a diferencia de las restricciones PRIMARY KEY, las restricciones UNIQUE admiten
valores NULL. Sin embargo, de la misma forma que cualquier valor incluido en una
restricción UNIQUE, sólo se admite un valor NULL por columna.
Es posible hacer referencia a una restricción UNIQUE con una restricción FOREIGN KEY.
Definiciones DEFAULT
Cada columna de un registro debe contener un valor, aunque sea un valor NULL. Puede
haber situaciones en las que deba cargar una fila de datos en una tabla, pero no conozca el
valor de una columna o el valor ya no exista. Si la columna acepta valores NULL, puede
cargar la fila con un valor NULL. Pero, dado que puede no resultar conveniente utilizar
columnas que acepten valores NULL, una mejor solución podría ser establecer una definición
DEFAULT para la columna siempre que sea necesario. Por ejemplo, es habitual especificar el
valor cero como valor predeterminado para las columnas numéricas, o N/D (no disponible)
como valor predeterminado para las columnas de cadenas cuando no se especifica ningún
valor.
Ejemplo fecha datetime default getdate() indica que el valor predeterminado de fecha es la
fecha actual del sistema.
4. Regla de integridad referencial
Son reglas de integridad controladas por el DBGS
Restricciones PRIMARY KEY
Una tabla suele tener una columna o una combinación de columnas cuyos valores identifican
de forma única cada fila de la tabla. Estas columnas se denominan claves principales de la
tabla y exigen la integridad de entidad de la tabla. Puede crear una clave principal mediante
la definición de una restricción PRIMARY KEY cuando cree o modifique una tabla.
Una tabla sólo puede tener una restricción PRIMARY KEY y ninguna columna a la que se
aplique una restricción PRIMARY KEY puede aceptar valores NULL. Debido a que las
restricciones PRIMARY KEY garantizan datos únicos, con frecuencia se definen en una
columna de identidad.
Cuando especifica una restricción PRIMARY KEY en una tabla, Database Engine (Motor de
base de datos) exige la unicidad de los datos mediante la creación de un índice único para
las columnas de clave principal. Este índice también permite un acceso rápido a los datos
57

cuando se utiliza la clave principal en las consultas. De esta forma, las claves principales que
se eligen deben seguir las reglas para crear índices únicos.
Si se define una restricción PRIMARY KEY para más de una columna, puede haber valores
duplicados dentro de la misma columna, pero cada combinación de valores de todas las
columnas de la definición de la restricción PRIMARY KEY debe ser única.
Como se muestra en la siguiente ilustración, las columnas ProductID y VendorID de la
tabla ProductVendor forman una restricción PRIMARY KEY compuesta para esta tabla.
Así se garantiza que la combinación de ProductID y VendorID es única.
Cuando trabaja con combinaciones, las restricciones PRIMARY KEY relacionan una tabla con
otra. Por ejemplo, para determinar los proveedores que suministran determinados
productos, puede utilizar una combinación de tres elementos entre las tablas Vendedor,
Production.Product y ProductVendor. Puesto que ProductVendor contiene las columnas
de ProductID y VendorID, se puede obtener acceso a las tablas Product y Vendor
mediante su relación con ProductVendor.
Restricciones FOREIGN KEY
Una clave externa (FK) es una columna o combinación de columnas que se utiliza para
establecer y exigir un vínculo entre los datos de dos tablas. Puede crear una clave externa
mediante la definición de una restricción FOREIGN KEY cuando cree o modifique una tabla.
En una referencia de clave externa, se crea un vínculo entre dos tablas cuando las columnas
de una de ellas hacen referencia a las columnas de la otra que contienen el valor de clave
principal. Esta columna se convierte en una clave externa para la segunda tabla.
Por ejemplo, la tabla Sales.SalesOrderHeader de la base de datos AdventureWorks
tiene un vínculo a la tabla Sales.SalesPerson porque existe una relación lógica entre
pedidos de ventas y personal de ventas. La columna SalesPersonID de la tabla
SalesOrderHeader coincide con la columna de clave principal de la tabla SalesPerson. La
58

columna SalesPersonID de la tabla SalesOrderHeader es la clave externa para la tabla
SalesPerson.
No es necesario que una restricción FOREIGN KEY esté vinculada únicamente a una
restricción PRIMARY KEY de otra tabla; también puede definirse para que haga referencia
a las columnas de una restricción UNIQUE de otra tabla. Una restricción FOREIGN KEY
puede contener valores NULL, pero si alguna columna de una restricción FOREIGN KEY
compuesta contiene valores NULL, se omitirá la comprobación de los valores que componen
la restricción FOREIGN KEY. Para asegurarse de que todos los valores de la restricción
FOREIGN KEY compuesta se comprueben, especifique NOT NULL en todas las columnas
que participan.
59

Si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la
clave primaria a la que hace referencia, o bien, deben ser completamente nulos.
Actualización y borrado de registros
La regla de integridad referencial se enmarca en términos de estados de la base de datos:
indica lo que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión es ¿qué
hacer si estando en un estado legal, llega una petición para realizar una operación que
conduce a un estado ilegal? Existen dos opciones: rechazar la operación, o bien aceptar la
operación y realizar operaciones adicionales compensatorias que conduzcan a un estado
legal.
Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres
preguntas:
Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos?
Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave ajena?
Restringir: no se permite borrar la tupla referenciada.
Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas
que la referencian mediante la clave ajena.
Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen
a nulo la clave ajena (sólo si acepta nulos).
Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria de
la tupla referenciada por la clave ajena?
Restringir: no se permite modificar el valor de la clave primaria de la tupla
referenciada.
Propagar: se modifica el valor de la clave primaria de la tupla referenciada y
se propaga la modificación a las tuplas que la referencian mediante la clave
ajena.
Anular: se modifica la tupla referenciada y las tuplas que la referenciaban
ponen a nulo la clave ajena (sólo si acepta nulos).
5. Otras reglas de integridad
• Disparadores o triggers
Combinan los enfoques declarativo (en la condición) y procedimental (en la
acción),
Pueden ser tan complejas como imponga la semántica del mundo real en cuanto a la
acción, y bastantes complejas en la condición (todo lo que permite la proposición
60

lógica mediante la que se expresa la condición),
El cumplimiento de la condición dispara la acción,
Son más flexibles que las restricciones de acción específica.
SQL Server TechCenter. Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm.
http://technet.microsoft.com/es-es/library/ms191236.aspx
61

5. Teoría De La Normalización
La primera aproximación del diccionario de datos (el diccionario de datos es la definición de
los campos o atributos contenidos en las tablas y se define usando DDL), presenta ciertos
problemas de redundancia, dependencia, etc. Es necesario optimizar el diseño para
conservar la consistencia e integridad de los datos y a la vez optimizar el espacio de
almacenamiento eliminando la redundancia. Para esto se lleva a cabo un proceso que se
llama NORMALIZACIÓN y comprende varias Formas Normales.
La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar,
como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de
lógica cuando se trataba de manipular los datos. De esta forma la normalización ayuda a
clarificar la base de datos ya organizarla en partes más pequeñas y más fáciles de entender,
además de otras ventajas destacables como la disminución de espacio en disco.
5.1. El concepto de dependencia funcional
Es el concepto más importante en el diseño de esquemas relacionales. Una dependencia
funcional es una restricción entre dos conjuntos de atributos de la base de datos.
Para entender el concepto vamos a hacer una serie de suposiciones:
Vamos a suponer que el esquema de base de datos relacional tiene una serie de atributos
A1, A2, A3, ..., An.. y que la base de datos se describe como un solo esquema de relación
universal R={A1, A2, A2,....,An}; es como si tuviéramos una sola tabla, pero solo para
explicar el concepto. La dependencia funcional es una restricción , que vamos a denotar
como X->Y, donde X e Y son dos subconjuntos de R, sobre las posibles tuplas, registros o
filas que podrían formar un ejemplar de relación en R. La restricción dice que para
cualesquier dos tuplas t1 y t2 tales que el valor t1[X] = t2[X], debemos tener t1[Y] =
t2[Y]; es decir, que los valores del componente Y de una tupla dependen de los valores del
componente X. En otras palabras podríamos decir que los valores del componente X (Que
denominaremos Miembro izquierdo) determinan de manera única los valores del
componente Y (que denominaremos Miembro derecho).
Así que si una restricción de R dice que no puede haber más de una tupla con un valor X, se
dice que X es una clave candidata. Esto implica que para todo subconjunto de atributos Y
de R X->Y.
Ejemplo: Veamos la siguiente definición o esquema funcional:
TERCERO {Tercero, Nombre, NSS, Apellidos, Dirección, Es_Cliente, Es_Proveedor, Fecha}
Veamos las dependencias funcionales:
Tercero-> Nombre.
NSS ->Nombre
62

Tercero -> NSS
{Tercero,NSS} -> Nombre
5.2. Qué es la normalización?
Se entiende por normalización la descomposición o subdivisión de una relación en dos o más
relaciones para evitar la redundancia; en definitiva, que "cada hecho esté en su lugar".
La normalización es el proceso mediante el cual se transforman datos complejos a un
conjunto de estructuras de datos más pequeñas, que además de ser más simples y más
estables, son más fáciles de mantener. También se puede entender la normalización como
una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar
un esquema que minimice los problemas de lógica. Cada regla está basada en la que le
antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos en un
solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a
errores de lógica cuando se trataban de manipular los datos. La normalización también hace
las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las
cosas al máximo. Lo hacemos con casi todo, desde los animales hasta con los automóviles.
Vemos una imagen de gran tamaño y la hacemos más simple agrupando cosas similares
juntas. Las guías que la normalización provee crean el marco de referencia para simplificar
una estructura de datos compleja.
Otra ventaja de la normalización de base de datos es el consumo de espacio. Una base de
datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos
repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en
disco.
El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto
puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso,
así como las razones para hacerlo de esta manera.
5.3. Proceso de normalización
El proceso de normalización es un estándar que consiste, básicamente, en un proceso de
conversión de las relaciones entre las entidades, evitando:
La redundancia de los datos: repetición de datos en un sistema.
Anomalías de actualización: inconsistencias de los datos como resultado de
datos redundantes y actualizaciones parciales.
Anomalías de borrado: pérdidas no intencionadas de datos debido a que se
han borrado otros datos.
Anomalías de inserción: imposibilidad de adicionar datos en la base de datos
debido a la ausencia de otros datos.
63

5.4. Grados de normalización
Existen básicamente tres niveles de normalización: Primera Forma Normal (1NF), Segunda
Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas tiene sus
propias reglas. Cuando una base de datos se conforma a un nivel, se considera normalizada
a esa forma de normalización. No siempre es una buena idea tener una base de datos
conformada en el nivel más alto de normalización, puede llevar a un nivel de complejidad
que pudiera ser evitado si estuviera en un nivel más bajo de normalización.
En la tabla siguiente se describe brevemente en qué consiste cada una de las reglas, y
posteriormente se explican con más detalle.
Regla Descripción
Primera Forma
Normal (1FN)
Una relación R se encuentra en 1FN si y solo sí por cada
renglón columna contiene valores atómicos.
Abreviada como 1FN, se considera que una relación se
encuentra en la primera forma normal cuando cumple lo
siguiente:
Las celdas de las tablas poseen valores simples y no se
permiten grupos ni arreglos repetidos como valores, es
decir, contienen un solo valor por cada celda.
Todos los ingresos en cualquier columna (atributo) deben
ser del mismo tipo.
Cada columna debe tener un nombre único.
Dos filas o renglones de una misma tabla no deben ser
idénticas, aunque el orden de las filas no es importante.
Segunda Forma
Normal (2FN)
Para definir formalmente la segunda forma normal
requerimos saber que es una dependencia funcional:
Consiste en edificar que atributos dependen de otro(s)
atributo(s).
Una relación se encuentra en segunda forma normal,
cuando cumple con las reglas de la primera forma normal
y todos sus atributos que no son claves (llaves)
dependen por completo de la clave . De acuerdo con esta
definición, cada tabla que tiene un atributo único como
clave, está en segunda forma normal.
Tercera Forma
Normal (3FN)
Para definir formalmente la 3FN necesitamos definir
dependencia transitiva: En una afinidad (tabla
bidimensional) que tiene por lo menos 3 atributos
64

(A,B,C) en donde A determina a B, B determina a C
entonces A determina a C.
Forma Normal de
Boyce Codd
Una relación R esta en FNBC si y solo si cada
determinante es una llave candidato.
Ejemplo
Trabajador(cedula, nombre, cargo, prima)
Pero el cargo determina la prima
Cuarta forma
normal
Existe una dependencia de valores múltiples cuando una
afinidad tiene por lo menos tres atributos, dos de los
cuales poseen valores múltiples y sus valores dependen
solo del tercer atributo, en otras palabras en la afinidad R
(A,B,C) existe una dependencia de valores múltiples si A
determina valores múltiples de B, A determina valores
múltiples de C, y B y C son independientes entre sí.
Para entender mejor aún esto consideremos una afinidad
(tabla) llamada estudiante que contiene los siguientes
atributos: Claves, estudiante, Especialidad y Curso
En la tabla anterior Clave estudiante determina valores
múltiples de especialidad y clave estudiante determina
valores múltiples de curso, pero especialidad y curso son
independientes entre sí.
Las dependencias de valores múltiples se definen de la siguiente
manera: Clave ->->Especialidad y Clave->->Curso; Esto se lee
"Clave multidetermina a Especialidad, y clave multidetermina a
Curso
Otras formas
normales
Existen otras dos formas normales, la llamada quinta
forma normal (5FN) que no detallo por su dudoso valor
práctico ya que conduce a una gran división de tablas,
pero que no pueden reconstruirse.
y la forma normal dominio / clave (FNDLL) de la que no existe
método alguno para su implantación.

5.5. ¿Qué tan lejos debe llevar la normalización?
La siguiente decisión es ¿qué tan lejos debe llevar la normalización? La normalización es una
ciencia subjetiva. Determinar las necesidades de simplificación depende de nosotros. Si
nuestra base de datos va a proveer información a un solo usuario para un propósito simple y
existen pocas posibilidades de expansión, normalizar los datos hasta la 3FN quizá sea algo
65

exagerado. Las reglas de normalización existen como guías para crear tablas que sean
fáciles de manejar, así como flexibles y eficientes. A veces puede ocurrir que normalizar los
datos hasta el nivel más alto no tenga sentido.
¿Se están dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad
prácticas?. Éstas son el tipo de cosas que nosotros como diseñadores de la base de datos,
necesitamos decidir, y la experiencia y el sentido común nos pueden auxiliar para tomar la
decisión correcta. La normalización no es una ciencia exacta, más bien subjetiva.
Existen seis niveles más de normalización que no se han discutido aquí. Ellos son Forma
Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma
Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de
Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de
normalización pueden llevar las cosas más allá de lo que necesitamos. Éstas existen para
hacer una base de datos realmente relacional. Tienen que ver principalmente con
dependencias múltiples y claves relacionales.
Para complementar este tema ver video (CD de Actividades).
Ejemplo Primera forma normal (1NF)
Se dice que una tabla se encuentra en primera forma normal (1NF) si y solo si cada uno de
los campos contiene un único valor para un registro determinado. Supongamos que
deseamos realizar una tabla para guardar los cursos que están realizando los alumnos de un
determinado centro de estudios, podríamos considerar el siguiente diseño:
Imagen basada en la dirección:
http://perso.wanadoo.es/aldomartin1/noreyalre.htm
Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36
Adaptación: Equipo Técnico P.A.V.
Podemos observar que el registro de código 1 si cumple la primera forma normal, cada
campo del registro contiene un único dato, pero no ocurre así con los registros 2 y 3 ya que
66

en el campo cursos contiene más de un dato cada uno. La solución en este caso es crear dos
tablas del siguiente modo:
Obtenida en la Fecha: agosto 17 de 2008 hora: 14.36 Adaptación: Equipo Técnico P.A.V.
Como se puede comprobar ahora todos los registros de ambas tablas contienen valores
únicos en sus campos, por lo tanto ambas tablas cumplen la primera forma normal.
Una vez normalizada la tabla en 1NF, podemos pasar a la segunda forma normal.
Ejemplo Segunda forma normal (2NF)
La segunda forma normal compara todos y cada uno de los campos de la tabla con la clave
definida. Si todos los campos dependen directamente de la clave se dice que la tabla está es
segunda forma normal (2NF).
Supongamos que construimos una tabla con los años que cada empleado ha estado
trabajando en cada departamento de una empresa:
67

Tomando como punto de partida que la clave de esta tabla está formada por los campos
código de empleado y código de departamento, podemos decir que la tabla se encuentra en
primera forma normal, por tanto vamos a estudiar la segunda:
1. El campo nombre no depende funcionalmente de toda la clave, sólo depende del
código del empleado.
2. El campo departamento no depende funcionalmente de toda la clave, sólo del código
del departamento.
3. El campo años si que depende funcionalmente de la clave ya que depende del código
del empleado y del código del departamento (representa el número de años que cada
empleado ha trabajado en cada departamento)
Por tanto, al no depender todos los campos de la totalidad de la clave la tabla no está en
segunda forma normal, la solución es la siguiente:
68

69

Podemos observar que ahora si se encuentras las tres tabla en segunda forma normal,
considerando que la tabla A tiene como índice el campo Código Empleado, la tabla B Código
Departamento y la tabla C una clave compuesta por los campos Código Empleado y Código
Departamento.
Ejemplo Tercera forma normal (3NF)
Se dice que una tabla está en tercera forma normal si y solo si los campos de la tabla
dependen únicamente de la clave, dicho en otras palabras los campos de las tablas no
dependen unos de otros. Tomando como referencia el ejemplo anterior, supongamos que
cada alumno sólo puede realizar un único curso a la vez y que deseamos guardar en que
aula se imparte el curso. A voz de pronto podemos plantear la siguiente estructura:
Estudiemos la dependencia de cada campo con respecto a la clave código:
Nombre depende directamente del código del alumno.
Curso depende de igual modo del código del alumno.
El aula, aunque en parte también depende del alumno, está más ligado al curso que
el alumno está realizando.
Por esta última razón se dice que la tabla no está en 3NF. La solución sería la siguiente:
70

Una vez conseguida la segunda forma normal, se puede estudiar la cuarta forma normal.
Ejemplo Cuarta forma normal (4NF)
Una tabla está en cuarta forma normal si y sólo si para cualquier combinación clave - campo
no existen valores duplicados. Veámoslo con un ejemplo:
71

Comparemos ahora la clave (Figura) con el atributo Tamaño, podemos observar que
Cuadrado Grande está repetido; igual pasa con Círculo Azul, entre otras. Estas repeticiones
son las que se deben evitar para tener una tabla en 4NF.
La solución en este caso sería la siguiente:
Ahora si tenemos nuestra base de datos en 4NF.
ibid, pg, 23
Normalización de Bases de Datos. Obtenido en Internet el 23 de Octubre de 2008.
Hora: 9.50 pm.. http://www.trucostecnicos.com/trucos/ver.php?id_art=278
Dependencia funcional e independencia, manual de la Universidad de Málaga.
Obtenido en Internet el 23 de Octubre de 2008. Hora: 9.50 pm.
http://ftp.medprev.uma.es/libro/node33.htm
Normalización de base de datos, Prof. Manuel Torres Remon. Obtenido en Internet el
23 de Octubre de 2008. Hora: 9.50 pm.
http://www.monografias.com/trabajos5/norbad/norbad.shtml
72

6. Lenguaje Sql
SQL: Lenguaje de consulta estructurado, Permite definir y manipular la base de datos, este
lenguaje se compone de:
DDL: Lenguaje de definición de datos
6.1. Comandos DDL
Comando Descripción
CREATE
Utilizado para crear nuevas tablas, campos
e índices.
DROP Empleado para eliminar tablas e índices
ALTER
Utilizado para modificar las tablas agregando campos o
cambiando la definición de los campos.
DML: Lenguaje de manipulación de datos
6.2. Comandos DML
SELECT
Utilizado para consultar registros de la base de datos que satisfagan un
criterio determinado
INSERT
Utilizado para cargar lotes de datos en la base de datos en una única
operación.
UPDATE Utilizado para modificar los valores de los campos y registros especificados
DELETE Utilizado para eliminar registros de una tabla de una base de datos
6.3. Cláusulas
Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea
seleccionar o manipular.
FROM
Utilizada para especificar la tabla de la cual se van a seleccionar los
registros
WHERE
Utilizada para especificar las condiciones que deben reunir los registros que
se van a seleccionar
GROUP
BY
Utilizada para separar los registros seleccionados en grupos específicos
73

74
HAVING Utilizada para expresar la condición que debe satisfacer cada grupo
ORDER
BY
Utilizada para ordenar los registros seleccionados de acuerdo con un orden
específico
6.4. Operadores Lógicos
Operador Uso
AND
Es el “y” lógico. Evalúa dos condiciones y devuelve un
valor de verdad sólo si ambas son ciertas.
OR
Es el “o” lógico. Evalúa dos condiciones y devuelve un
valor de verdad si alguna de las dos es cierta.
NOT Negación lógica. Devuelve el valor contrario de la expresión.
6.5. Operadores de Comparación
Operador Uso
< Menor que
> Mayor que
<> Distinto de
<= Menor ó Igual que
>= Mayor ó Igual que
BETWEEN Utilizado para especificar un intervalo de valores.
LIKE Utilizado en la comparación de un modelo
In Utilizado para especificar registros de una base de datos
6.6. Funciones de Agregado
Las unciones de agregado se usan dentro de una cláusula SELECT
en grupos de registros para devolver un único valor que se aplica a un
grupo de registros.
AVG Utilizada para calcular el promedio de los valores de un campo determinado
COUNT Utilizada para devolver el número de registros de la selección
SUM
Utilizada para devolver la suma de todos los valores de un campo
determinado
MAX Utilizada para devolver el valor más alto de un campo especificado
MIN Utilizada para devolver el valor más bajo de un campo especificado

Unidad 4
Manipulación De
Una Base De
Datos Relacional
Una vez diseñada y estandarizada la base de datos esta se puede
implementar y manipular utilizando un DBGS, estos tienen
herramientas que permiten la definición y la manipulación de la base de
datos, además incluyen un lenguaje llamado el SQL (Structured Query
Language) es un lenguaje de programación diseñado para almacenar,
manipular y recuperar datos almacenados en bases de datos
relacionales.

1. Reconocimiento Del Sistema
Gestor De Bases De Datos
Relaciónales
Sql Server es un servidor de bases de datos.
Iniciar a sql server
Inicio > programas >
Clic en Enterprise Manager
Ya con los objetos, vamos a abrir local, y vemos que ya existen varias bases de datos, lo
que significa que existen bases de datos para el sistema y otras son modelos de ejemplos
para el aprendizaje.
76

Este es el símbolo de la base de datos:
Desplegar la opción data transformation que son los DTS (Transformación de datos entre
sistemas: entre Excel – Access, etc transforma un formato de una base de datos en otro
ósea importación y exportación de datos entre diferentes bases de datos. Con un dts coge
un archivo plano y lo transforma)
En manager.
77

Dentro del grupo de trabajo tengo un servidor (local, pero pueden existir muchos más como
para cartera, contabilidad, etc) y dentro de los servidores hay varios objetos y dentro de los
objetos hay database (bases de datos). Esto suple la limitante que tenia Access.
1.1. Crear Una Base De Datos
Cuando se crea una base de datos, es importante comprender cómo SQL Server almacena
los datos para poder calcular y especificar la cantidad de espacio en disco que hay que
asignar a los archivos de datos y registros de transacciones. Aunque SQL Server
automáticamente incrementa el tamaño asignado a los ficheros de bases de datos
dinámicamente, para tener un rendimiento óptimo del sistema (evitar fragmentación de los
ficheros), se recomienda ser "precisos" a la hora de definir el tamaño de la base de datos.
1.2. Ficheros de la base de datos
Todas las bases de datos tienen un archivo de datos principal (.mdf), y uno o varios archivos
de registro de transacciones (.ldf). Una base de datos también puede tener archivos de
datos secundarios (.ndf). La extensión definida para cada tipo de archivos es libre, pero
como buenas prácticas se suele seguir el modelo de extensiones recomendado por Microsoft
(mdf, ldf, y ndf). El proceso de creación de la base de datos, consiste en hacer una copia de
la base de datos model, que incluye las tablas del sistema. La ubicación predeterminada
para todos los archivos de datos y registros de transacciones es C:Archivos de
programaMicrosoft SQL ServerMSSQL.1MSSQLData.
La base de datos puede configurarse con tres modelos de recuperación en caso de
fallo del sistema (FULL, BULK_LOGGED, y SIMPLE); evalúa cada modelo en base a
las necesidades del sistema que estés implementando.
1.3. Creación de base de datos desde SQL Server
2005 Management Studio Express
SQL Server Management Studio Express es la herramienta de administración incluida con
SQL Server Express; la herramienta no fue incluida en la primera distribución de SQL Server
Express, y se puede descargar de forma gratuita de la siguiente url:
Microsoft SQL Server Management Studio Express - Community Technology Preview (CTP)
November 2005:
Para crear una base de datos desde SQL Server 2005 Management Studio, expande la lista
de bases de datos, de la lista de instancias de SQL Server 2005 registradas, y selecciona la
opción "New database":
78

Deberás rellenar el nombre de base de datos, nombres lógico y físico de los archivos
relacionados, y tamaño de los ficheros, así como su crecimiento:
79

Y deberás establecer el modo de recuperación de la base de datos; en la versión Express al
crear una base de datos por defecto se establece como recuperación SIMPLE:
Para famializarte con la sintaxis del lenguaje T-SQL, te recomiendo que utilices la
opción de menú script (en recuadro verde en las dos imágenes anteriores), que
mostrará la instrucción T-SQL correspondiente a las operaciones que has ido
configurando en las distintas opciones.
1.4. Consideraciones
Dependiendo de las necesidades a cubrir del sistema de base de datos a desarrollar, deberás
configurar los archivos de una forma u otra; por ejemplo, en grandes sistemas llegarás a
configurar niveles de redundancia de discos (RAID), y repartirás la información de las tablas
en distintos ficheros. Aunque no está soportado en la versión Express, funcionalidades del
producto como Particionado de datos, llegan a ser primordiales, y es un factor a considerar
desde el momento de diseño del sistema.
80

Basesde datos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Basesde datos

Similar a Basesde datos (20)

Basesde datos