Antologia 4A JEMIMA

INSTITUTO TECNOLGICO SUPERIOR DE TEPEACA
INGENIERA EN SISTEMAS COMPUTACIONALES

FUNDAMENTOS DE BASES DE DATOS
CUARTO SEMESTRE GRUPO A
DOCENTE: ING. INS LEN FLOREZ
ANTOLOGA
UNIDAD 1. SISTEMAS GESTORES DE BASES DE DATOS, UNIDAD 2 DISEO DE
BASES DE DATOSY EL MODELO E-R
UNO
ALUMNO
MATRCULA
NOMBRE (S)
CORREO ELECTRNICO
11791033
CANO VAZQUEZ JEMIMA
jhemyvazquez@gmail.com
FECHA DE ENTREGA:
10:00 hrs.
HORA:
LUGAR: Saln de clases
20 DE MARZO DE 2014 ( Debe ir subrayado)
Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia

Humana
NDICE
UNIDAD 1. SISTEMAS GESTORES DE BASES DE DATOS.................................4
1.1.
Objetivo de las Bases de Datos...................................................................4
1.2.
reas de Aplicacin de los Sistemas de Bases de datos............................5
1.3.
Modelos de datos.........................................................................................6
1.4.
Arquitectura del Sistema Gestor de Bases de datos...................................8
1.5.
Niveles de abstraccin...............................................................................10
1.6.
Tipos de usuarios........................................................................................11
1.7.
Tipos de lenguajes.....................................................................................13
UNIDAD 2. DISEO DE BASES DE DATOS Y EL MODELO E-R........................17

2.1 El Proceso de Diseo.....................................................................................17
2.2 Modelo Entidad-Relacin...............................................................................17
2.3 Restricciones..................................................................................................19
2.4 Diagramas E-R...............................................................................................21
2.5 Diseo con diagramas E-R............................................................................23
2.6 Conjunto de entidades dbiles.......................................................................24
2.7 Modelo E-R extendido....................................................................................24
2.8 Otros aspectos del diseo de bases de datos...............................................25
2.9 La Notacin E-R con UML..............................................................................25
UNIDAD 3. MODELO RELACIONAL......................................................................28
3.1 Estructura bsica............................................................................................28
3.2 Esquema de las bases de datos....................................................................31
3.3 Claves.............................................................................................................32
3.4 Lenguajes de consulta...................................................................................35
UNIDAD 4. DISEO DE LAS BASES DE DATOS RELACIONALES.....................37
4.1 Caractersticas del diseo relacional.............................................................37
4.2 Dominios atmicos y la primera forma normal...............................................40
4.3 Dependencias funcionales.............................................................................44
4.4 Segunda forma normal...................................................................................45
4.5 Tercera forma normal.....................................................................................48
INGENIERA DE SOFTWARE / AVANCE No. 1

4.6 Forma normal Boyce-Codd............................................................................50
4.7 Algoritmos de descomposicin.......................................................................52
4.8 Formas normales superiores..........................................................................53
4.9 Integridad de las bases de datos...................................................................54
REFERENCIAS.......................................................................................................57
Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

Pgina 3 de 59
NDICE DE FIGURAS
UNIDAD 1. SISTEMAS GESTORES DE BASES DE DATOS.

1.1.
Objetivo de las Bases de Datos.
Un sistema gestor de bases de datos (SGBD) consiste en una coleccin de datos

interrelacionados y un conjunto de programas para acceder a dichos datos. La coleccin de
datos, normalmente denominada base de datos, contiene informacin relevante para una
empresa. El objetivo principal de un SGBD es proporcionar una forma de almacenar y
recuperar la informacin de una base de datos de manera que sea tanto prctica como
eficiente.
Los sistemas de bases de datos se disean para gestionar grandes cantidades de
informacin. La gestin de los datos implica tanto la definicin de estructuras para almacenar
la informacin como la provisin de mecanismos para la manipulacin de la informacin.
Adems los sistemas de base de datos deben proporcionar la fiabilidad de la informacin
almacenada, a pesar de las cadas del sistema o los intentos de acceso sin autorizacin.
Una base de datos de puede definir como:
Una coleccin interrelacionada de datos, almacenados en un conjunto sin

redundancias innecesarias cuya finalidad es la de servir a una o ms aplicaciones de
la manera ms eficiente.
Conjunto de datos organizados con caractersticas afines entre s, que identifican a un

ente en especial, cualquier coleccin de informacin interrelacionada, es una base de
datos.
Conjunto auto descriptivo de registros integrados; auto descriptivo ya que puede

contener informacin del usuario, descripcin de la Base de Datos, que nos permiten
representar las relaciones entre los datos. En donde la informacin que se tiene
almacenada est disponible para todos los usuarios del sistema, en los que los datos
redundantes pueden eliminarse o al menos minimizarse.
Los componentes de una base de datos son:

Los datos: El componente fundamental de una base de datos son los datos que estn
interrelacionados entre s, formando un conjunto con un mnimo de redundancias.
El software: los datos, para que puedan ser utilizados por diferentes usuarios y diferentes
aplicaciones, deben estar estructurados y almacenados de forma independiente de las
aplicaciones. Para ello se utiliza un software o conjunto de programas que acta de interfaz
entre los datos y las aplicaciones. A este software se le denomina Sistema de Gestin de Base

Pgina 5 de 59

de Datos (SGBD). El SGBD crea y organiza la base de datos, y adems atiende todas las
solicitudes de acceso hechas a la base de datos tanto por los usuarios como por las
aplicaciones.
Recurso Humano:
Informtico: son los profesionales que definen y preparan la base de datos.
Usuarios: Son los que tienen acceso a la base de datos para ingresar o manipular la
informacin contenida en esta, dependiendo del nivel de usuario o control de
seguridad establecido.
1.2.
reas de Aplicacin de los Sistemas de Bases de datos.
Las bases de datos son ampliamente usadas. Las siguientes son algunas de sus aplicaciones
ms representativas:
Banca: Para llevar el control de la informacin de los clientes, cuentas, prestamos y todas las
transacciones bancarias.
Lneas areas: Para llevar el control de todas las planificaciones de vuelos de una aerolnea y
las reservaciones hechas por los clientes. Las lneas areas fueron de las primeras en usar
las base de datos de forma distribuida geogrficamente (las terminales situadas en todo el
mundo accedan al sistema de base de datos centralizado a travs de las lneas telefnicas y
otras redes de datos).
Escuelas: Para llevar el control de los estudiantes, horarios, cursos, inscripciones y
calificaciones.
Transacciones de tarjetas de crdito: Para llevar el control de compras con tarjeta de crdito y
generacin mensual de estados de cuenta de los usuarios.
Telecomunicaciones: Para guardar un registro de las llamadas realizadas, generacin mensual
de factures, control del saldo de las tarjetas de prepago y almacenar informacin sobre las
redes de comunicaciones.
Finanzas: Para almacenar informacin sobre grandes empresas, ventas y compras de
documentos formales financieros, como bolsa y bonos.
Ventas: Para tener el control de la informacin de los clientes, productos y la informacin de
las ventas generadas de forma diaria o mensual segn el control que se desee tener.

Pgina 6 de 59

Produccin: Para la gestin de la cadena de produccin, seguimiento de la produccin y
control de inventarios en almacn.
Recursos humanos: Para llevar el control de informacin sobre los empleados, salaries,
impuestos y con esto poder generar la nmina.
1.3.
Modelos de datos.
Bajo la estructura de la base de datos se encuentra el modelo de datos: una coleccin de

herramientas conceptuales para describir los datos, las relaciones, la semntica y las
restricciones de consistencia.
Dentro del modelo de datos se encuentran:
Modelo Entidad-relacin: El modelo de datos entidad-relacin (E-R) est basado en una
percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados
entidades, y de relaciones entre estos objetos. Una entidad es una cosa u objeto en el mundo
real que es distinguible de otros objetos. Las entidades se describen en una base de datos
mediante un conjunto de atributos. Una relacin es una asociacin entre varias entidades.
La estructura lgica general de una base de datos se puede expresar grficamente mediante
un diagrama ER, que consta de los siguientes componentes:
Rectngulos, que representan conjuntos de entidades.

Elipses, que representan atributos.
Rombos, que representan relaciones entre conjuntos de entidades.
Lneas, que unen los atributos con los conjuntos de entidades y los conjuntos
de entidades con las relaciones.
Ejemplo de un diagrama entidad-relacin (Figura 1.1).

Pgina 7 de 59
Modelo Relacional.
En el modelo relacional se utiliza un grupo de tablas para representar los datos y las
relaciones entre ellos. Cada tabla est compuesta por varias columnas, y cada columna tiene
un nombre nico.
El modelo relacional es un ejemplo de un modelo basado en registros. Los modelos basados
en registros se denominan as porque la base de datos se encuentra en registros de formato
fijo de varios tipos. Cada tabla contiene registros de un tipo particular. Cada tipo de registro
define un nmero fijo de campos, o atributos. Las columnas de la tabla corresponden a los
atributos del tipo de registro.
El modelo de datos relacional es el modelo de datos ms ampliamente usado, y una amplia
mayora de sistemas de bases de datos actuales se basan en el modelo relacional.
El modelo relacional se encuentra a un nivel de abstraccin inferior al modelo de datos E-R
(Entidad-Relacin). Los diseos de bases de datos a menudo se realizan en el modelo E-R, y
despus se traducen al modelo relacional.
Modelo Orientado a Objetos. El modelo orientado a objetos se puede observar como una
extensin del modelo E-R con las nociones de encapsulacin, mtodos (funciones) e identidad
de objeto. El modelo de datos relacional orientado a objetos combina las caractersticas del
modelo de datos orientado a objetos y el modelo de datos relacional.
Los modelos de datos semiestructurados permiten la especificacin de datos donde los
elementos de datos individuales del mismo tipo pueden tener diferentes conjuntos de
atributos.

Pgina 8 de 59

Esto es diferente de los modelos de datos mencionados anteriormente, en los que cada
elemento de datos de un tipo particular debe tener el mismo conjunto de atributos. El lenguaje
de marcas extensible (XML, eXtensible Markup Language) se usa ampliamente para
representar datos semi-estructurados.
Histricamente, otros dos modelos de datos, el modelo de datos de red y el modelo de datos
jerrquico, precedieron al modelo de datos relacional. Estos modelos estuvieron ligados
fuertemente a la implementacin subyacente y complicaban la tarea del modelado de datos.
Como resultado se usan muy poco actualmente, excepto en el cdigo de bases de datos
antiguo que an est en servicio en algunos lugares.
1.4.
Arquitectura del Sistema Gestor de Bases de datos.
La mayora de usuarios de un sistema de bases de datos no estn situados actualmente junto

al sistema de bases de datos, sino que se conectan a l a travs de una red.
Se puede diferenciar entonces entre las mquinas cliente, en donde trabajan los usuarios
remotos de la base de datos, y las mquinas servidor, en las que se ejecuta el sistema de
bases de datos.
Las aplicaciones de bases de datos se dividen usualmente en dos o tres partes, como se
ilustra en la Figura 1.2. En una arquitectura de dos capas, la aplicacin se divide en un
componente que reside en la mquina cliente, que llama a la funcionalidad del sistema de
bases de datos en la mquina servidor mediante instrucciones del lenguaje de consultas. Los
estndares de interfaces de programas de aplicacin como ODBC y JDBC se usan para la
interaccin entre el cliente y el servidor.

Pgina 9 de 59
En cambio, en una arquitectura de tres capas, la mquina cliente acta simplemente como
frontal y no contiene ninguna llamada directa a la base de datos. En su lugar, el cliente se
comunica con un servidor de aplicaciones, usualmente mediante una interfaz de formularios.
El servidor de aplicaciones, a su vez, se comunica con el sistema de bases de datos para
acceder a los datos.
La lgica de negocio de la aplicacin, que establece las acciones a realizar bajo determinadas
condiciones, se incorpora en el servidor de aplicaciones, en lugar de ser distribuida a mltiples
clientes. Las aplicaciones de tres capas son ms apropiadas para grandes aplicaciones, y
para las aplicaciones que se ejecutan en World Wide Web.

Pgina 10 de 59

1.5.
Niveles de abstraccin.
Para que el sistema sea til debe recuperar los datos eficientemente. Esta preocupacin ha
conducido al diseo de estructuras de datos complejas para la representacin de los datos en
la base de datos. Como muchos usuarios de sistemas de bases de datos no estn
familiarizados con computadores, los desarrolladores esconden la complejidad a los usuarios
a travs de varios niveles de abstraccin para simplificar la interaccin de los usuarios con el
sistema, en la figura 1.3, se esquematizan los tres niveles de abstraccin de base de datos. A
continuacin se definen los principales niveles de abstraccin:
Nivel fsico. El nivel ms bajo de abstraccin describe cmo se almacenan realmente los
datos. En el nivel fsico se describen en detalle las estructuras de datos complejas de bajo
nivel.
En el nivel fsico, un registro cliente, cuenta o empleado se puede describir como un bloque de
posiciones almacenadas consecutivamente (por ejemplo, palabras o bytes). El compilador del
lenguaje esconde este nivel de detalle a los programadores. Anlogamente, el sistema de
base de datos esconde muchos de los detalles de almacenamiento de nivel inferior a los
programadores de bases de datos. Los administradores de bases de datos pueden ser
conscientes de ciertos detalles de la organizacin fsica de los datos.
Nivel lgico. El siguiente nivel ms alto de abstraccin describe qu datos se almacenan en la
base de datos y qu relaciones existen entre esos datos. La base de datos completa se
describe as en trminos de un nmero pequeo de estructuras relativamente simples. En el
nivel lgico cada registro de este tipo se describe mediante una definicin de tipo y se define
la relacin entre estos tipos de registros. Los programadores, cuando usan un lenguaje de
programacin, trabajan en este nivel de abstraccin. De forma similar, los administradores de
bases de datos trabajan habitualmente en este nivel de abstraccin.
Nivel de vistas. El nivel ms alto de abstraccin describe slo parte de la base de datos
completa. Muchos usuarios del sistema de base de datos no necesitan toda esta informacin.
En su lugar, tales usuarios necesitan acceder slo a una parte de la base de datos. Para que
su interaccin con el sistema se simplifique, se define la abstraccin del nivel de vistas.
En el nivel de vistas, los usuarios de computadoras ven un conjunto de programas de
aplicacin que esconden los detalles de los tipos de datos. Anlogamente, en el nivel de vistas
se definen varias vistas de una base de datos y los usuarios de la misma ven nica y
exclusivamente esas vistas. Adems de esconder detalles del nivel lgico de la base de datos,

Pgina 11 de 59

las vistas tambin proporcionan un mecanismo de seguridad para evitar que los usuarios
accedan a ciertas partes de la base de datos. Por ejemplo, los cajeros de un banco ven
nicamente la parte de la base de datos que tiene informacin de cuentas de clientes; no
pueden acceder a la informacin referente a los sueldos de los empleados.
1.6.
Tipos de usuarios.
Un objetivo principal de un sistema de bases de datos es recuperar informacin y almacenar

nueva informacin en la base de datos. Las personas que trabajan con una base de datos se
pueden catalogar como usuarios de bases de datos o como administradores de bases de
datos, los cuales se describen a continuacin.
Usuarios de bases de datos e interfaces de usuario.
Hay cuatro tipos diferentes de usuarios de un sistema de base de datos, diferenciados por la
forma en que ellos esperan interactuar con el sistema.

Pgina 12 de 59
Usuarios normales.
Programadores de aplicaciones.
Los usuarios sofisticados.
Usuarios especializados.
Usuarios normales. Son usuarios no sofisticados que interactan con el sistema mediante la
invocacin de alguno de los programas de aplicacin. Por ejemplo considere que un usuario
desea consultar su saldo a travs de la web. Tal usuario nicamente puede acceder a un
formulario donde introduce su nmero de cuenta y clave de autentificacin, en ese momento
un programa de aplicacin en el servidor Web verifica su nmero de cuenta y clave, si son
vlidos entonces recuera el saldo de la cuenta y muestra la informacin al usuario.
La interfaz de usuario para los usuarios normales en este caso es una interfaz de formularios,
donde el usuario solo puede llenar y realizar las acciones que se le indiquen en el formulario.
Los usuarios normales pueden tambin simplemente leer informes generados por la base de
datos.
Programadores de aplicaciones. Son profesionales informticos que escriben programas de
aplicacin. Los programadores de aplicacin pueden elegir entre muchas herramientas para
desarrollar interfaces de usuario, las interfaces desarrolladas son las que deben tener
interaccin con la base de datos.
Los usuarios sofisticados. Son los usuarios que interactan con el sistema sin programas
escritos, se encargan de formar sus consultas en un lenguaje de consulta de base de datos.
Cada una de estas consultas se enva al procesador de consultas, cuya funcin es
transformar que se encuentran en un lenguaje de manipulacin de datos (LMD) a
instrucciones que el gestor de almacenamiento entienda. Los analistas que envan las
consultas para explorar los datos en la base de datos entran en esta categora.
Existen herramientas de procesamiento analtico que le permiten a los analistas simplificar su
trabajo, permitiendo una seleccin muy especfica de registros, examinar datos con ms
detalle, recopilacin de datos que les ayudan a encontrar ciertas clases de patrones de datos
existentes dentro de la base de datos que pueden ser un auxiliar para la toma de decisiones
en una empresa.
Usuarios especializados. Son usuarios sofisticados que escriben aplicaciones de base de
datos especializadas que no son adecuadas en el marco de procesamiento de datos
tradicional, dentro de estas estn los sistemas de diseo asistido por computadora, sistemas
de base de conocimientos y sistemas expertos, sistemas que almacenan los datos con tipos

Pgina 13 de 59

de datos complejos (por ejemplo, datos grficos y datos de audio) y sistemas de modelado del
entorno.
Administrador de la base de datos.
Una de las principales razones de usar SGBDs (Sistemas Manejadores de Base de Datos) es
tener un control centralizado tanto de los datos como de los programas que acceden a esos
datos. La persona que tiene este control central sobre el sistema se llama administrador de la
base de datos (ABD). Las funciones del ABD incluyen las siguientes:
Definicin del esquema. El ABD crea el esquema original de la base de datos escribiendo un
conjunto de instrucciones de definicin de datos en el LDD.
Definicin de la estructura y del mtodo de acceso.
Modificacin del esquema y de la organizacin fsica. Los ABD realizan cambios en el
esquema y en la organizacin fsica para reflejar las necesidades cambiantes de la
organizacin, o para alterar la organizacin fsica para mejorar el rendimiento.
Concesin de autorizacin para el acceso a los datos. La concesin de diferentes tipos de
autorizacin permite al administrador de la base de datos determinar a qu partes de la base
de datos puede acceder cada usuario. La informacin de autorizacin se mantiene en una
estructura del sistema especial que el sistema de base de datos consulta cuando se intenta el
acceso a los datos en el sistema.
Mantenimiento rutinario. Algunos ejemplos de actividades rutinarias de mantenimiento del
administrador de la base de datos son:
Copia de seguridad peridica de la base de datos, bien sobre cinta o sobre servidores
remotos, para prevenir la prdida de datos en caso de desastres como inundaciones.
Asegurarse de que haya suficiente espacio libre en disco para las operaciones
normales y aumentar el espacio en disco segn sea necesario.
Supervisin de los trabajos que se ejecuten en la base de datos y asegurarse de que

el rendimiento no se degrada por tareas muy costosas iniciadas por algunos usuarios.
1.7.
Tipos de lenguajes.
Tipos de lenguajes.
Un sistema de bases de datos proporciona un lenguaje de definicin de datos para especificar
el esquema de la base de datos y un lenguaje de manipulacin de datos para expresar las
consultas a la base de datos y las modificaciones.

Pgina 14 de 59

Lenguaje de definicin de datos.
Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas
mediante un lenguaje especial llamado lenguaje de definicin de datos (LDD).
Por ejemplo, la siguiente instruccin en el lenguaje SQL define la tabla clientes:
create table clientes ( clave_cliente char(10), nombre char(20) )
La ejecucin de la instruccin LDD (Lenguaje de Definicin de Datos) anterior crea la tabla
clientes. Adems, actualiza un conjunto especial de tablas denominado diccionario de datos o
directorio de datos.
Un diccionario de datos contiene metadatos, es decir, datos acerca de los datos. El esquema
de una tabla es un ejemplo de metadatos. Un sistema de base de datos consulta el diccionario
de datos antes de leer o modificar los datos reales.
Especificamos el almacenamiento y los mtodos de acceso usados por el sistema de bases
de datos por un conjunto de instrucciones en un tipo especial de LDD denominado lenguaje de
almacenamiento y definicin de datos. Estas instrucciones definen los detalles de
implementacin de los esquemas de base de datos, que se ocultan usualmente a los usuarios.
Lenguaje de manipulacin de datos
La manipulacin de datos es:
La recuperacin de informacin almacenada en la base de datos.

La insercin de informacin nueva en la base de datos.
El borrado de informacin de la base de datos.
La modificacin de informacin almacenada en la base de datos.
Un lenguaje de manipulacin de datos (LMD) es un lenguaje que permite a los usuarios
acceder o manipular los datos organizados mediante el modelo de datos apropiado. Hay dos
tipos bsicamente:
LMDs procedimentales. Requieren que el usuario especifique qu datos se necesitan y

cmo obtener esos datos.

Pgina 15 de 59
LMDs declarativos (tambin conocidos como LMDs no procedimentales). Requieren

que el usuario especifique qu datos se necesitan sin especificar cmo obtener esos
datos.
Los LMDs declarativos son ms fciles de aprender y usar que los LMDs procedimentales. Sin
embargo, como el usuario no especifica cmo conseguir los datos, el sistema de bases de
datos tiene que determinar un medio eficiente de acceder a los datos. El componente LMD del
lenguaje SQL es no procedimental. Una consulta es una instruccin de solicitud para
recuperar informacin. La parte de un LMD que implica recuperacin de informacin se llama
lenguaje de consultas.
Aunque tcnicamente sea incorrecto, en la prctica se usan los trminos lenguaje de
consultas y lenguaje de manipulacin de datos como sinnimos.
Esta consulta en el lenguaje SQL encuentra el nombre del cliente cuyo identificador de cliente
es 12345.
Esta consulta en el lenguaje SQL encuentra el nombre del cliente cuyo identificador de cliente
es 12345.
select clientes.nombre from clientes where clientes.clave_cliente= '12345'
Lo que est haciendo la consulta anterior es seleccionando (select) el nombre del cliente
(clientes.nombre) de (from) la tabla clientes, donde (where) la clave del cliente
(clientes.clave_cliente) sea igual a '12345'.
1.8 Tpicos selectos de bases de datos.
Las Bases de Datos (BD), si bien representan a una tecnologa que ya cuenta con ms de 40
aos de historia, an sigue desarrollndose y diversificndose. La razn de este desarrollo
continuo se debe principalmente a que en la actualidad las BD abordan problemas en los que
se integran tecnologas que tienen una amplia aceptacin, entre ellas podemos mencionar la
tecnologa de Orientacin a Objetos, presente en las BD Orientadas a Objetos (BDOO), la
tecnologa de Redes de Computadoras, presente en las BD Distribuidas (BDD), la tecnologa
de Georeferenciacin y Vectorizacin encontradas en las BD Espaciales utilizadas en los
Sistemas de Informacin Geogrfica (SIGs), las tecnologas de acceso a informacin semiestructurada y la Web soportadas por las BD XML, las tecnologas para gestin de grandes

Pgina 16 de 59

almacenes de datos reflejada en las BD Multidimencionales, etc. Dado que el universo en el
que se desenvuelven las BD es muy extenso, sera imposible tratar de cubrirlo en un slo
curso, por lo que este curso se disea con el fin de abordar algunos Tpicos Selectos, en
donde la seleccin y profundidad de cada tema se ajusta de acuerdo a criterios de relevancia,
actualidad y pertinencia emanados de necesidades que surgen de los trabajos de
investigacin generados en el Cinvestav en el rea de BD .

Pgina 17 de 59
UNIDAD 2. DISEO DE BASES DE DATOS Y EL MODELO E-R.

2.1 El Proceso de Diseo.
Los diseadores entrevistan a los futuros usuarios de la base de datos para recoger y
documentar sus necesidades de informacin. En paralelo, conviene definir los requerimientos
funcionales que consisten en operaciones (transacciones) que se aplicarn a la base de
datos, e incluyen la obtencin de datos y la actualizacin.
Diseo conceptual. Una vez recogidos todos los requerimientos, el siguiente paso es crear un
esquema conceptual para la base de datos mediante un modelo de datos conceptual de alto
nivel.
El esquema conceptual contiene una descripcin detallada de los requerimientos de
informacin de los usuarios, y contiene descripciones de los tipos de datos, relaciones entre
ellos y restricciones.
Diseo lgico de la base de datos (transformacin de modelo de datos) El siguiente paso en el
proceso de diseo consiste en implementar de hecho la base de datos con un SGBD (Sistema
Manejador de Base de Datos) comercial, transformando el modelo conceptual al modelo de
datos empleados por el SGBD (entidad-relacin, jerrquico, red o relacional).
Diseo fsico de la base de datos En este paso se especifican las estructuras de
almacenamiento internas y la organizacin de los archivos de la base de datos.
2.2 Modelo Entidad-Relacin.
El modelo de datos entidad-relacin (E-R) est basado en una percepcin del mundo real
consistente en objetos bsicos llamados entidades y de relaciones entre estos objetos.
Se desarroll para facilitar el diseo de bases de datos permitiendo la especificacin de un
esquema de la empresa que representa la estructura lgica completa de una base de datos.

Pgina 18 de 59

El modelo E-R (Entidad-Relacin) adems de entidades y relaciones representan las uniones
que los contenidos de la base de datos deben cumplir. Una unin es la correspondencia de
cardinalidades, que expresan el nmero de entidades con las que otra entidad se puede
asociar a travs de un conjunto de relaciones.
Conceptos bsicos: Existen tres conceptos fundamentales que se emplean en el modelo de
datos E-R (Entidad-Relacin): conjunto de entidades, conjunto de relaciones y atributos, las
cuales se definen a continuacin.
Entidad: Se puede definir cono Entidad a cualquier objeto, real o abstracto, que existe en un
contexto determinado o puede llegar a existir y del cual deseamos guardar informacin. Una
entidad tiene propiedades y valores que identifican a un sujeto u objeto el cual existe y es
distinguible de otros objetos, se representan por un conjunto de atributos, ejemplo entidad
cliente: rfc, nombre, direccin, telfono.
Un conjunto de entidades es un conjunto de entidades del mismo tipo que comparten las
mismas propiedades, o atributos.
Atributos: Los Atributos son caractersticas o propiedades asociadas a la entidad que toman
valor en una instancia particular. Ejemplo: nombre, cdula, telfono. Cada entidad tiene un
valor para cada uno de sus atributos.
Dominio del atributo: Para cada atributo hay un conjunto de valores permitidos, llamados el
dominio, o el conjunto de valores, de ese atributo.
Un atributo, como se usa en el modelo E-R, se puede caracterizar por los siguientes tipos de
atributo:
Atributos simples: Un atributo simple es aquel que no se puede subdividir, por ejemplo
la edad y el sexo de una persona.
Atributos compuestos: Un atributo compuesto, es un atributo que puede ser

subdividido en otros atributos adicionales, por ejemplo la direccin de una persona,
puede subdividirse en calle, nmero, cdigo postal, etc.
Atributos monovalorados y multivalorados.
Atributos derivados.
Llave o clave de la relacin: Es el identificador nico de cada tupla.

Clave primaria: clave candidata que el diseador elige de la base de datos como el medio
principal de identificar entidades dentro de un conjunto de entidades.
Clave compuesta: Una clave compuesta de ms de un atributo.

Pgina 19 de 59

Clave candidata: Cualquier conjunto de atributos que puede ser elegido como clave de una
relacin.
Clave externa: Un conjunto de atributos o un atributo, en una relacin que constituyen una
clave en alguna otra relacin, usada para establecer enlaces lgicos entre relaciones.
Tupla: Conjunto de atributos que representan a una unidad. Valor nulo: El valor dado a un
atributo en una tupla si el atributo es inaplicable o su valor es desconocido.
Cardinalidad: Numero especifico de ocurrencias de una entidad, asociadas con una ocurrencia
de la entidad relacionada, esto es el nmero mximo de instancias de un conjunto de objetos
que puede estar relacionado con una sola instancia de otro conjunto de objetos.
Relacin: Una relacin es una asociacin entre entidades, se denomina de igual modo a una
tabla que se genera a partir de la relacin o asociacin de dos o ms tablas o entidades
existentes.
2.3 Restricciones.
Un esquema de desarrollo E-R puede definir ciertas restricciones a las que los contenidos de
la base de datos se deben adaptar. En este apartado se examina la correspondencia de
cardinalidades y las restricciones de participacin, que son dos de los tipos ms importantes
de restricciones.
La correspondencia de cardinalidades, o razn de cardinalidad, expresa el nmero de
entidades a las que otra entidad puede estar asociada va un conjunto de relaciones.
Reglas de cardinalidad:
Cardinalidad de uno a uno: Una carnidalidad de la interrelacin que es 1 en ambas
direcciones. Cuando un registro de una tabla slo puede estar relacionado con un nico
registro de la otra tabla y viceversa. En este caso la clave fornea se ubica en alguna de las 2
tablas.
Cardinalidad de uno a muchos: Cuando un registro de una tabla (tabla secundaria) slo puede
estar relacionado con un nico registro de la otra tabla (tabla principal) y un registro de la tabla
principal puede tener ms de un registro relacionado en la tabla secundaria. En este caso la
clave fornea se ubica en la tabla secundaria.
Cardinalidad de muchos a muchos: Cuando un registro de una tabla puede estar relacionado
con ms de un registro de la otra tabla y viceversa. En este caso las dos tablas no pueden

Pgina 20 de 59

estar relacionadas directamente, se tiene que aadir una tabla entre las dos (Tabla dbil o de
vinculacin) que incluya los pares de valores relacionados entre s.
El nombre de tabla dbil deviene de que con sus atributos propios no se puede encontrar la
clave, por estar asociada a otra entidad. La clave de esta tabla se conforma por la unin de los
campos claves de las tablas que relaciona.
Reglas que determinan las interrelaciones (cardinalidad).
Regla 1. Si dos tablas tienen una interrelacin de uno a uno (1 a 1), entonces el campo clave
de una de las tablas debe aparecer en la otra tabla.
Regla 2. Si dos tablas tienen una interrelacin de uno a muchos (1 a *), entonces el campo
clave de la tabla del (1) debe aparecer en la tabla del muchos (*).
Regla 3. Si dos tablas tienen una interrelacin de muchos a muchos (* a *), entonces debe
crearse una tabla que tenga los campos claves de las dos tablas.
Ejemplos:
Las relaciones entre entidades se generan en dos direcciones, 1. Si se quiere definir la
relacin entre un empleado y un departamento se especifica de la siguiente manera:
Un empleado pertenece a un departamento.
En un departamento estn asignados muchos empleados.
Esta relacin es de tipo 1:M
2. Para una interrelacin entre un supervisor y un departamento, la cardinalidad es de una a

una, en donde el 1 es representado por 1.
Un supervisor, supervisa un departamento.
Un departamento es supervisado por una persona.
En este caso la relacin es de uno a uno.

Pgina 21 de 59

3. Para una interrelacin entre un supervisor y empleados, la cardinalidad es de una a mucho,
en donde l muchos puede ser representado por un (*), o la letra m.
Un supervisor supervisa a muchos empleados.
Un empleado es supervisado por un supervisor.
En este caso la relacin es de uno a muchos.
4. En una relacin entre alumnos y materias cursadas, la cardinalidad es de muchos a

muchos.
Un alumno cursa muchas materias.
Una materia la cursan muchos alumnos.
En este caso es una interrelacin de muchos a muchos.
Co
mo en este ejemplo se tiene una relacin de muchos a muchos, se genera una tercera entidad
dbil (Cursa), que se forma con las llaves primarias de la entidad Alumno y Materias.
2.4 Diagramas E-R.

La estructura lgica general de una base de datos se puede expresar grficamente mediante
un diagrama E-R. Los diagramas son simples y claros, cualidades que pueden ser
responsables del amplio uso del modelo E-R. Tal diagrama consta de los siguientes
componentes principales:
Rectngulos,
que
representan
conjuntos
de
entidades. Elipses,
que
representan
atributos. Rombos, que representan relaciones. Lneas, que unen atributos a conjuntos de
entidades y conjuntos de entidades a conjuntos de relaciones. Elipses dobles, que
representan
atributos
multivalorados. Elipses
discontinuas,
que
denotan
atributos
derivados. Lneas dobles, que indican participacin total de una entidad en un conjunto de
relaciones. Rectngulos dobles, que representan conjuntos de entidades dbiles.

Pgina 22 de 59
Ejemplo de un diagrama Entidad-Relacin:
En este modelo se representa a las entidades cliente y cuenta, adems de una tabla generada
por la relacin denominada tiene.
La tabla cliente contiene los atributos: Id_cliente, Nombre, Direccin, Telfono. La tabla cuenta
contiene los atributos: Numero_cuenta, Saldo.

Pgina 23 de 59
2.5 Diseo con diagramas E-R.

El modelo de datos E-R da una flexibilidad sustancial en el diseo de un esquema de bases
de datos para modelar una empresa dada. En este apartado se considera cmo un diseador
de bases de datos puede seleccionar entre el amplio rango de alternativas. Entre las
decisiones que se toman estn las siguientes:
Si se usa un atributo o un conjunto de entidades para representa un objeto.
Si un concepto del mundo real se expresa ms exactamente mediante un conjunto de

entidades o mediante un conjunto de relaciones.
Si se usa una relacin ternaria o un par de relaciones binaras.
Si se usa un conjunto de entidades fuertes o dbiles; un conjunto de entidades fuertes

y sus conjuntos de entidades dbiles dependientes se pueden considerar como un
objeto en la base de datos, debido a que la existencia de las entidades dbiles
depende de la entidad fuerte.
Un modelo de datos de alto nivel sirve al diseador de la base de datos para proporcionar un
marco conceptual en el que especificar de forma sistemtica los requisitos de datos de los
usuarios de la base de datos que existen, y cmo se estructurar la base de datos para
completar estos requisitos. La fase inicial del diseo de bases de datos, por tanto, es
caracterizar completamente las necesidades de datos esperadas por los usuarios de la base
de datos. El resultado de esta fase es una especificacin de requisitos del usuario. Esta
estructura general se puede expresar grficamente mediante un diagrama E-R.
A continuacin, el diseador elige un modelo de datos y, aplicando los conceptos del modelo
de datos elegido, traduce estos requisitos a un esquema conceptual de la base de datos. El
esquema desarrollado en esta fase de diseo conceptual proporciona una visin detallada del
desarrollo. Debido a que slo se ha estudiado el modelo E-R hasta ahora, se usar ste para
desarrollar el esquema conceptual. En trminos del modelo E-R, el esquema especifica todos
los conjuntos de entidades, conjuntos de relaciones, atributos y restricciones de
correspondencia.
El diseador revisa el esquema para confirmar que todos los requisitos de datos se satisfacen
realmente y no hay conflictos entre s. Tambin se examina el diseo para eliminar
caractersticas redundantes. Lo importante en este punto es describir los datos y las
relaciones, ms que especificar detalles del almacenamiento fsico.

Pgina 24 de 59

Un esquema conceptual completamente desarrollado indicar tambin los requisitos
funcionales de la empresa. En una especificacin de requisitos funcionales los usuarios
describen los tipos de operaciones (o transacciones) que se realizarn sobre los datos.
Algunos ejemplos de operaciones son la modificacin o actualizacin de datos, la bsqueda y
recuperacin de datos especficos y el borrado de datos. En esta fase de diseo conceptual se
puede hacer una revisin del esquema para encontrar los requisitos funcionales.
El proceso de trasladar un modelo abstracto de datos a la implementacin de la base de datos
consta de dos fases de diseo finales. En la fase de diseo lgico, el diseador traduce el
esquema conceptual de alto nivel al modelo de datos de la implementacin del sistema de
base de datos que se usar. El diseador usa el esquema resultante especfico a la base de
datos en la siguiente fase de diseo fsico, en la que se especifican las caractersticas fsicas
de la base de datos.
2.6 Conjunto de entidades dbiles.

Las entidades que no tienen atributos llave se conocen como entidades dbiles. Las entidades
de este tipo se identifican relacionndolas con otras entidades en combinacin con algunos de
sus atributos. Esa otra entidad se denomina entidad fuerte o propietaria.
Una entidad dbil siempre tiene una dependencia de existencia (restriccin de participacin
total) con respecto a la entidad fuerte.
Como ya se mencionaba anteriormente cuando se tiene una relacin de muchos a muchos
entre dos entidades se genera una tercera entidad denominada "dbil", una entidad dbil no
tiene llave primaria y sus atributos principales son las llaves primarias de las entidades que se
estn relacionando.
2.7 Modelo E-R extendido.

Aunque los conceptos bsicos de E-R pueden modelar la mayora de las caractersticas de las
bases de datos, algunos aspectos de una base de datos pueden ser ms adecuadamente
expresados mediante ciertas extensiones del modelo E-R bsico. A continuacin se definen

Pgina 25 de 59

las caractersticas E-R extendidas de especializacin, generalizacin, conjuntos de entidades
de nivel ms alto y ms bajo, herencia de atributos y agregacin.
La especializacin y la generalizacin definen una relacin de contenido entre un conjunto de
entidades de nivel ms alto y uno o ms conjuntos de entidades de nivel ms bajo. La
especializacin es el resultado de tomar un subconjunto de un conjunto de entidades de nivel
ms alto para formar un conjunto de entidades de nivel ms bajo. La generalizacin es el
resultado de tomar la unin de dos o ms conjuntos disjuntos de entidades (de nivel ms bajo)
para producir un conjunto de entidades de nivel ms alto. Los atributos de los conjuntos de
entidades de nivel ms alto los heredan los conjuntos de entidades de nivel ms bajo.
La agregacin es una abstraccin en la que los conjuntos de relaciones (junto con sus
conjuntos de entidades asociados) se tratan como conjuntos de entidades de nivel ms alto, y
pueden participar en las relaciones.
2.8 Otros aspectos del diseo de bases de datos.

Al momento de disear un modelo de base de datos se deben considerar los siguientes
aspectos:
Obtener los Requisitos de datos.
Designacin de los conjuntos de entidades
Designacin de los conjuntos de relaciones
Realizar el diseo del Diagrama E-R
2.9 La Notacin E-R con UML.

Los diagramas entidad-relacin ayudan a modelar el componente de representacin de datos
de un sistema software. La representacin de datos, sin embargo, slo forma parte de un
diseo completo de un sistema.
Otros componentes son modelos de interaccin del usuario con el sistema, especificacin de
mdulos funcionales del sistema y su interaccin, etc. El lenguaje de modelado unificado
(UML, Unified Modeling Language) es un estndar propuesto para la creacin de

Pgina 26 de 59

especificaciones de varios componentes de un sistema software. Algunas de las partes de
UML son:
Diagrama de clase. Un diagrama de clase es similar a un diagrama E-R.
Diagrama de caso de uso. Los diagramas de caso de uso muestran la interaccin

entre los usuarios y el sistema, en particular los pasos de las tareas que realiza el
usuario.
Diagrama de actividad. Los diagramas de actividad describen el flujo de tareas entre

varios componentes de un sistema.
Diagrama de implementacin. Los diagramas de implementacin muestran los

componentes del sistema y sus interconexiones tanto en el nivel del componente
software como el hardware.
Un tpico es una idea o un tema en especfico, en este caso bases de datos, as que
resumiremos los tpicos ms importantes, o selectos de bases de datos.
Una base de datos es una biblioteca donde a de mantener listas de los libros que posee, de
los usuarios que tiene de sus productos, ventas y empleados.
A este tipo de informacin se le llama datos.
Un gestor de base de datos es un programa que permite introducir y almacenar datos,
ordenarlos y manipularlos. Organizarlos de manera significativa para que se pueda obtener
informacin no visible como totales, tendencias o relaciones de otro tipo.
Debe permitir:
-Introducir datos
-Almacenar datos
-Recuperar datos y trabajar con ellos
Tabla o fichero, registro y campo
Un programa de base de datos almacena la informacin que introducimos en forma de tablas
como las que podemos ver, por ejemplo, en una lista telefnica.

Pgina 27 de 59

Registro: es el concepto bsico en el almacenamiento de datos. El registro agrupa la
informacin asociada a un elemento de un conjunto y est compuesto por campos.
Tabla: conjunto de registros homogneos con la misma estructura.
Tipos de base de datos: planas y relacionales
Para hacer una base de datos que cumpla las funciones de listn telefnico necesitamos una
sola tabla, pero puede haber casos en los que necesitemos ms de una.
A esta forma de organizar la base de datos mediante distintas tablas relacionadas por campos
comunes se le llama base de datos relacional.
No todos los programas de gestin de base de datos tienen esta capacidad de manejar bases
de datos relacionales, por eso, antes de elegir uno deberemos considerar si necesitamos o no
esta capacidad.
Esta base de datos relacional estar formada por tablas. Con la caracterstica de que las
mismas se relacionan entre s mediante uno o ms campos. Se puede decir que cada objeto
de la realidad ser una tabla en nuestra base de datos y que hay que buscar la manera de
reflejar las relaciones antes mencionadas.
Para este tipo de bases de datos con mltiples usuarios aparecieron las llamadas bases de
datos de red. Estas estn situadas en un nico ordenador llamado servidor (generalmente
ordenadores de gran potencia) y se puede acceder a ellas desde terminales u ordenadores
con un programa que permita el acceso a ella los llamados clientes. Los Gestores de bases
de datos de este tipo permiten que varios usuarios hagan operaciones sobre ella al mismo
tiempo: uno puede hacer una consulta al mismo tiempo que otro, situado en un lugar diferente,
est introduciendo datos en la base.
Utilidad de una base de datos: Las tres cosas bsicas que debe permitir un gestor de base de
datos son: introducir datos, almacenarlos y recuperarlos.
Al mismo tiempo permiten otra serie de funciones que hacen de ellos herramientas
incomparablemente superiores a los mtodos tradicionales de almacenamiento de datos:
archivadores, carpetas, etc.
Cualquier gestor debe permitir: ordenar los datos, realizar bsquedas, mostrar distintas vistas
de los datos, realizar clculos sobre ellos, resumirlos, generar informes a partir de ellos,
importarlos y exportarlos.

Pgina 28 de 59
UNIDAD 3. MODELO RELACIONAL

El modelo relacional se ha establecido actualmente como el principal modelo de datos para
las aplicaciones de procesamiento de datos. Ha conseguido la posicin principal debido a su
simplicidad, que facilita el trabajo del programador en comparacin con otros modelos.
Una base de datos relacional consiste en un conjunto de tablas, a cada una de las cuales se
le asigna un nombre exclusivo. Cada tabla tiene una estructura parecida a la presentada en la
unidad 2, donde se representaron las bases de datos E-R mediante tablas.
3.1 Estructura bsica.

Una tabla en el modelo relacional viene a ser como una de las listas descritas anteriormente.
Una tabla o relacin es una matriz rectangular que almacena lneas con una estructura
concreta:
La primera lnea de una tabla, es una cabecera que indica el nombre de cada
columna. O sea, cada columna tiene asignado un nombre nico.
Cada lnea (excepto la primera) recibe el nombre de tupla, y almacena temes

concretos para cada columna.
Todas las filas deben ser diferentes entre s.
El orden de las filas y de las columnas carece de importancia a efectos del S.G.B.D.
Este hecho es el que verdaderamente diferencia las tablas relacionales del concepto
matemtico de relacin, en el que el orden de las columnas es fundamental.
Dominio de Valores. Los dominios a que puede pertenecer un atributo, suelen depender de los
que proporcione el S.G.B.D. que empleemos. Suelen ser comunes dominios como: Texto,
Nmero entero, Nmero decimal, Fecha, Hora, S/No, etc.
Por otro lado, un dominio como pueda ser Nmero entero, es un dominio cuyo conjunto de
valores es infinito, y dado que trabajamos con ordenadores, es imprescindible poner un lmite

Pgina 29 de 59

que permita almacenar un valor concreto debido a las limitaciones de memoria, y sobre todo al
hecho de que toda tupla debe poseer el mismo tamao.
Se trata de un modelo bastante potente y a la vez bastante simple, que nos representas
problemas. El elemento principal de este modelo es la relacin. Por lo que podemos decir que
una base de datos relacional est compuesta por un conjunto de relaciones.
Relacin: La relacin se representa mediante una tabla, esta tabla representa a lo que en el
modelo entidad-relacin llambamos entidad. Esta tabla contiene los atributos (columnas) y
las tuplas (filas).
Atributo: se trata de cada una de las columnas de la tabla. Vienen definidas por un nombre y
pueden contener un conjunto de valores.
Tupla: se trata de cada una de las filas de la tabla. Es importante sealar que no se pueden
tener tuplas duplicadas en una tabla.
Dominios: El dominio dentro de la estructura del modelo relacional es el conjunto de valores
que puede tomar un atributo. Existen dos tipos de dominios:
Dominios generales: son aquellos que estn comprendidos entre un mximo y un mnimo.
Dominios restringidos: son los que pertenecen a un conjunto de valores especficos.
Claves: Cada tupla de una tabla tiene que estar asociada a una clave nica que permita
identificarla. Una clave puede estar compuesta por uno o ms atributos.
Una clave tiene que ser nica dentro de su tabla y no se puede descartar ningn atributo de la
misma para identificar una fila.
Existen dos tipos de claves:
Clave prmaria (Primary Key): es el valor o conjunto de valores que identifican una fila dentro
de una tabla. Nunca puede ser NULL. Un ejemplo claro de clave primaria seria el DNI, que es
nico para cada persona y no puede ser NULL.

Pgina 30 de 59

Clave ajena (Foreign Key): es el valor o valores de una tabla que corresponde con el valor de
una clave primaria en otra tabla. Esta clave es la que representa las relaciones entre las
tablas.
Vistas: Se trata de una tabla ficticia la cual muestra atributos de otras tablas relacionadas. De
esta forma obtenemos los datos que nos interesan de una o varias tablas. Es importante
sealar que no se pueden realizar operaciones sobre vistas.
La relacin es el elemento bsico del modelo relacional, y se puede representar como una
tabla.
En ella podemos distinguir su nombre, un conjunto de columnas, denominadas atributos, que

representan propiedades de la tabla y que tambin estn caracterizadas por su nombre, y un
conjunto de filas llamadas tuplas, que contienen los valores que toma cada uno de los
atributos para cada elemento de la relacin.
Grado: nmero de atributos
Cardinalidad: nmero de tuplas
En una tabla se puede distinguir una cabecera que define la estructura de la tabla; es decir,
sus atributos con los dominios subyacentes, y un cuerpo que est formado por un conjunto de
tuplas que varan en el tiempo.
Esta representacin de la relacin como una tabla ha sido el origen de que los productos
relacionales y los usuarios utilicen habitualmente el nombre de tabla (en principio ajeno a la
teora relacional) para denominar las relaciones y, como consecuencia de ello, se llame filas a
las tuplas y columnas a los atributos; si bien, la terminologa es irrelevante y un producto no es
ms o menos relacional por utilizar una u otra terminologa.

Pgina 31 de 59
3.2 Esquema de las bases de datos.

Un esquema de bases de datos, junto con las dependencias de clave primaria y externa, se
puede mostrar grficamente mediante diagramas de esquema.
Ejemplo de un esquema de base de datos:
El esquema de una base de datos (en ingls, Database Schema) describe la estructura de
una Base de datos, en un lenguaje formal soportado por un Sistema administrador de Base de
datos (DBMS). En una Base de datos Relacional, el Esquema define sus tablas, sus campos
en cada tabla y las relaciones entre cada campo y cada tabla.

Pgina 32 de 59

El esquema es generalmente almacenado en un Diccionario de Datos. Aunque generalmente
el esquema es definido en un lenguaje de Base de datos, el trmino se usa a menudo para
referirse a una representacin grfica de la estructura de base de datos.
El esquema de una base de datos (en ingls, Database Schema) describe la estructura de
una Base de datos, en un lenguaje formal soportado por un Sistema administrador de Base de
datos (DBMS). En una Base de datos Relacional, el Esquema define sus tablas, sus campos
en cada tabla y las relaciones entre cada campo y cada tabla.
El esquema es generalmente almacenado en un Diccionario de Datos. Aunque generalmente

el esquema es definido en un lenguaje de Base de datos, el trmino se usa a menudo para
referirse a una representacin grfica de la estructura de base de datos (Diseo de lgico de
la base de datos).
3.3 Claves.
Una clave es un atributo o conjunto de atributos cuyo valor es nico y diferente para
cada tupla.
Tenemos dos claves potenciales, tambin llamadas claves candidatas.
De entre todas las claves candidatas, el administrador, cuando define la tabla, debe
decidir cul de ellas va a ser la clave principal o clave primaria, mientras que el resto
de las claves pasan a denominarse claves alternativas o claves alternas.
Si el esquema de una base de datos relacional se basa en las tablas derivadas de un

esquema E-R es posible determinar la clave primaria del esquema de una relacin a partir de

Pgina 33 de 59

las claves primarias de los conjuntos de entidades o de relaciones de los que se deriva el
esquema:
Conjunto de entidades fuertes. La clave primaria del conjunto de entidades se convierte en la
clave primaria de la relacin.
Conjunto de entidades dbiles. La tabla y, por tanto, la relacin correspondientes a un
conjunto de entidades dbiles incluyen:
Los atributos del conjunto de entidades dbiles.
La clave primaria del conjunto de entidades fuertes del que depende el conjunto de
entidades dbiles.
La clave primaria de la relacin consiste en la unin de la clave primaria del conjunto

de entidades fuertes y el discriminante del conjunto de entidades dbil.
Conjunto de relaciones. La unin de las claves primarias de los conjuntos de entidades

relacionados se transforma en una superclave de la relacin. Si la relacin es de varios a
varios, esta superclave es tambin la clave primaria.
En cualquier base de datos los registros incluidos en sus diferentes tablas deben estar
perfectamente identificados y de esto se encargan las claves o llaves. Trasladando este
concepto a la vida real, cada ciudadano tiene un nmero de CURP, puede haber dos personas
con igual nombre e incluso apellidos iguales, pero ambos se diferenciarn por su CURP, que
es nico en "teora".
Cada tabla debe contener al menos un campo que permita identificar unvocamente cada
registro. Este campo puede ser real, como el propio CURP de una persona. O puede ser un
valor que nos inventemos para conseguir el mismo fin, como un nmero que asignemos
automticamente a cada registro, asegurndonos (realmente lo har Base) de que no se
repita. Otra opcin es utilizar una combinacin de campos para identificar los registros de la
tabla. Por ejemplo podramos definir la combinacin de Nombre y Apellidos de nuestra tabla
para este fin. Sin embargo, existe la probabilidad de que haya alumnos con igual nombre y
apellidos, por lo que no sera una clave del todo vlida.

Pgina 34 de 59

Clave.
Es un conjunto de atributos que identifican de forma unvoca una entidad.
Superclave.
Una superclave es un conjunto de uno o ms atributos que, tomados colectivamente, permiten
identificar de forma nica una entidad en el conjunto de entidades.
Clave Principal.
Una clave principal es un campo (o conjunto de campos) que identifica inequvocamente un
registro. Es decir, es un campo que no admite valores duplicados en los registros.
Una clave principal contiene la informacin que necesita el gestor de bases de datos para
modificar el registro, y permite adems implementar la integridad referencial.
Las claves principales nos van a permitir:
Claves externas.
Una clave externa es un campo (o conjunto de campos), cuyos posibles valores estn
limitados a los que se hayan definido en otra tabla como clave principal.
Claves Candidatas.
Una caracterstica que debemos buscar siempre en las claves es que contenganel nmero
mnimo de atributos, siempre que mantengan su funcin. Diremos que una clave es mnima
cuando si se elimina cualquiera de los atributos que la componen, deja de ser clave. Si en una
entidad existe ms de una de estas claves mnimas, cada una de ellas es una clave
candidata.
Clave candidata: es cada una de las claves mnimas existente en un conjunto de entidades

Pgina 35 de 59

Claves de interrelaciones.
Tengamos en cuenta que para definir una interrelacin usaremos las claves primarias de las
entidades interrelacionadas. De este modo, el identificador de una interrelacin es el conjunto
de las claves primarias de cada una de las entidades interrelacionadas.
Clave Alternativa.
Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave
primaria, pero que tambin puede identificar de forma nica a una fila dentro de una tabla.
3.4 Lenguajes de consulta.

Un lenguaje de consulta es un lenguaje en el que un usuario solicita informacin de la base de
datos. Estos lenguajes suelen ser de un nivel superior que el de los lenguajes de
programacin
habituales.
Los
lenguajes
de
consulta
pueden
clasificarse
como
procedimentales o no procedimentales. En los lenguajes procedimentales el usuario instruye

al sistema para que lleve a cabo una serie de operaciones en la base de datos para calcular el
resultado deseado. En los lenguajes no procedimentales el usuario describe la informacin
deseada sin dar un procedimiento concreto para obtener esa informacin.
La mayor parte de los sistemas comerciales de bases de datos relacionales ofrecen un
lenguaje de consulta que incluye elementos de los enfoques procedimental y no
procedimental.
Un lenguaje de consulta es un lenguaje informtico usado para hacer consultas en bases de
datos y sistemas de informacin.
Los lenguajes de consulta pueden ser clasificados de acuerdo a si son lenguajes de consulta
de bases de datos o lenguajes de consulta de recuperacin de informacin. Algunos ejemplos
son:
.QL es un lenguaje de consulta propietario orientado a objetos para consultar
bases de datos relacionales;1
CODASYL;

Pgina 36 de 59
D es un lenguaje de consulta para sistemas de administracin de bases de
datos verdaderamente relacionales (truly relational database management systems TRDBMS);2
DMX es un lenguaje para modelos de minera de datos;
Datalog es un lenguaje de consulta para bases de datos deductivas;
ERROL es un lenguaje de consulta sobre el modelo entidad-relacin (ERM),
especialmente diseado para bases de datos relacionales;
Gellish English es un lenguaje que puede ser usado para consultas en bases de
datos Gellish English,3 para dilogos (pedidos y respuestas) como tambin para
modelado de informacin y modelado de conocimiento;
ISBL es un lenguaje de consulta para PRTV, uno de los ms recientes sistemas
de administracin de bases de datos;
MQL es un lenguaje de consulta de quimioinformtica para bsqueda de
subestructuras permitiendo propiedades nominales y numricas;
MDX es un lenguaje de consulta para bases de datos OLAP;
OQL es un lenguaje de consulta de objetos;
OPath, pensado para el uso consultando almacenes WinFS;
QUEL es un lenguaje de acceso a bases de datos relacionales, muy similar a
SQL;
SMARTS
es
el
estndar
de
quimioinformtica
para
bsqueda
de
subestructuras;5
SPARQL es un lenguaje de consulta para grafos RDF;

SQL es un lenguaje de consulta muy reconocido para bases de datos
relacionales;
SuprTool es un lenguaje de consulta propietario para SuprTool,6 un programa
de acceso a bases de datos para obtener datos en Image/SQL (TurboIMAGE) y bases

de datos Oracle;
TMQL Topo Magic Queeen Lion es un lenguaje de consulta para Topic Maps;
XQuery es un lenguaje de consulta para fuentes de datos XML;

Pgina 37 de 59
UNIDAD 4. DISEO DE LAS BASES DE DATOS RELACIONALES

El modelo relacional para la gestin de una base de datos es un modelo de datos basado en
la lgica de predicados y en la teora de conjuntos. Es el modelo ms utilizado en la actualidad
para modelar problemas reales y administrar datos dinmicamente.
Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San
Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base
de datos.
Su idea fundamental es el uso de relaciones. Estas relaciones podran considerarse en
forma lgica como conjuntos de datos llamados tuplas. Pese a que sta es la teora de las
bases de datos relacionales creadas por Edgar Frank Codd, la mayora de las veces se
conceptualiza de una manera ms fcil de imaginar, esto es, pensando en cada relacin como
si fuese una tabla que est compuesta por registros (cada fila de la tabla sera un registro o
tupla), y columnas (tambin llamadas campos).
4.1 Caractersticas del diseo relacional.

El modelo relacional, est basado en las relaciones lgicas entre los datos, este modelo
organiza y representa a los datos en forma de tablas de dos dimensiones, consistente en filas
y columnas de datos.
El concepto de base de datos relacional fue escrito por primera vez por el Dr. Codd en 1970 el
cual public un artculo en que aplicaba los conceptos de una rama de las matemticas
llamada algebra relacional, a los problemas de almacenar enormes cantidades de datos. Este
artculo dio inicio a un movimiento en la comunidad de las bases de datos que en muy poco
tiempo condujo a la definicin del modelo de base de datos relacionales.
El modelo relacional surge como un intento de simplificar la estructura de las bases de datos,
eliminando estructuras padre/hijo del modelo jerrquico de la base de datos y en su lugar
representar todos los datos en la base de datos como tablas conformada a su vez por
renglones y columnas con valores de datos.

Pgina 38 de 59

Este modelo, es un modelo simple, poderoso y formal de representar la realidad, que facilita la
construccin de consultas de usuario.
El objetivo del diseo de las bases de datos relacionales es la generacin de un conjunto de
esquemas relacionales que nos permita almacenar la informacin sin redundancias
innecesarias, pero que tambin nos permita recuperar fcilmente esa informacin.
Normalizacin:
La normalizacin de bases de datos relacionales toma un esquema relacional y le aplica un
conjunto de tcnicas para producir un nuevo esquema que representa la misma informacin
pero contiene menos redundancias y evita posibles anomalas en las inserciones,
actualizaciones y borrados. La tcnica de normalizacin es semejante a lo que comnmente
se dice de que un prrafo debe tener un solo tema, si un prrafo tiene ms de un tema, debe
dividirse en tantos prrafos como temas se consideren. La lgica que se aplica a la
normalizacin es cada afinidad normalizada tiene un solo tema, si tiene dos o ms, deber
fragmentarse en afinidades, cada una de las cuales tendr un solo tema.
Estas clases de afinidades y las tcnicas para prevenir las anomalas son llamadas formas
normales. Dependiendo de su estructura, una afinidad puede estar en primera forma normal,
segunda forma normal o alguna otra. En su artculo Ted Codd, estableci la primera, segunda
y tercera forma normal. Cada una de estas formas estn anidadas, esto es una afinidad que
est en tercera forma, debe estar en primera y segunda forma normal.
El modelo relacional para la gestin de una base de datos es un modelo de datos basado en
la lgica de predicados y en la teora de conjuntos. Es el modelo ms utilizado en la actualidad
para modelar problemas reales y administrar datos dinmicamente. Tras ser postuladas sus
bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no
tard en consolidarse como un nuevo paradigma en los modelos de base de datos.
Su idea fundamental es el uso de relaciones.
Estas relaciones podran considerarse en forma lgica como conjuntos de datos llamados
tuplas. Pese a que sta es la teora de las bases de datos relacionales creadas por Edgar
Frank Codd, la mayora de las veces se conceptualiza de una manera ms fcil de imaginar,
esto es, pensando en cada relacin como si fuese una tabla que est compuesta por registros
(cada fila de la tabla sera un registro o tupla), y columnas (tambin llamadas campos).

Pgina 39 de 59
En este modelo todos los datos son almacenados en relaciones, y como cada relacin es un
conjunto de datos, el orden en el que stos se almacenen no tiene relevancia (a diferencia de
otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es
ms fcil de entender y de utilizar por un usuario no experto. La informacin puede ser
recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder
para administrar la informacin.
Este modelo considera la base de datos como una coleccin de relaciones. De manera
simple, una relacin representa una tabla que no es ms que un conjunto de filas, cada fila es
un conjunto de campos y cada campo representa un valor que interpretado describe el mundo
real. Cada fila tambin se puede denominar tupla o registro y a cada columna tambin se le
puede llamar campo o atributo.
Para manipular la informacin utilizamos un lenguaje relacional, actualmente se cuenta con
dos lenguajes formales el lgebra relacional y el Clculo relacional. El lgebra relacional
permite describir la forma de realizar una consulta, en cambio, el Clculo relacional slo indica
lo que se desea devolver.
Esquema
Un esquema es la definicin de una estructura (generalmente relaciones o tablas de una base
de datos), es decir, determina la identidad de la relacin y que tipo de informacin podr ser
almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relacin.
Todo esquema constar de:
Nombre
de
la
relacin
(su
identificador).
Nombre de los atributos (o campos) de la relacin y sus dominios; el dominio de un

atributo o campo define los valores permitidos para el mismo, es equivalente al tipo de
dato por ejemplo character, integer, date, string, etc.
Instancias
Una instancia de manera formal es la aplicacin de un esquema a un conjunto finito de datos.
En palabras no tan tcnicas, se puede definir como el contenido de una tabla en un momento
dado, pero tambin es vlido referirnos a una instancia cuando trabajamos o mostramos

Pgina 40 de 59

nicamente un subconjunto de la informacin contenida en una relacin o tabla, como por
ejemplo:
4.2 Dominios atmicos y la primera forma normal.

La primera de las formas normales que se van a estudiar, la primera forma normal, impone un
requisito muy elemental a las relaciones; a diferencia de las dems formas normales, no exige
informacin adicional como las dependencias funcionales.
Un dominio es atmico si se considera que los elementos del dominio son unidades
indivisibles.
Una afinidad esta en primera forma normal, si la tupla tiene un campo definido como campo
clave y todos sus valores son atmicos para cada atributo en la relacin. Esto es que los
valores de los atributos no pueden ser un conjunto de valores o un grupo repetitivo.
Cualquier tabla de datos que cumpla con la definicin de una afinidad, se dice que est en
primera forma normal.
Si en la tabla encontramos grupos repetitivos es necesario crear una tabla de relacin que
interrelacione a las tablas determinadas.
Cuando pasamos al modelo relacional debemos aplicar ciertas reglas las de estandarizacin,
de normalizacin del todo las tablas, a este conjunto de reglas se le conoce con el nombre de
normalizacin de base de datos, que consiste en aplicar una serie de relacin las relaciones
obtenidas tras el paso del modelo entidad relacin al modelo relacional. Las base de datos
relacionales se normalicen para evitar redundancia de los datos, evitar problemas de
actualizacin de los datos en las tablas, para proteger la integridad de los datos. Aqu es
importante mencionar que tenemos tres tipo de integridades, la integridad de dominio que
como dijimos anteriormente limita el conjunto de datos posibles en una columna. La integridad
de identidad, que establece que cada fila debe ser nica y que no se permiten la duplicidad.

Pgina 41 de 59

La integridad referencial que plantean que cuando un atributo columna de una tabla hace
referencia a la informacin de la tabla.
En el modelo relacional es comn llamar tablas a una relacin aunque para que una tabla sea
considerada tabla de una relacin debe cumplir como algunas restricciones como que cada
tabla debe tener su nombre nico, que no pueda haber dos filas iguales, que todos los datos
en una columna debe ser del mismo tipo. Para poder cumplir con estos enunciados se crearon
entonces la relacin normalizacin que son seis reglas.
Normalizacin
El proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a las
relaciones obtenidas tras el paso del modelo entidad-relacin al modelo relacional. Las bases
de datos relacionales se normalizan para:

Pgina 42 de 59
La regla de normalizacin.
La primera regla de normalizacin dice que cada fila o tupla de una tabla la debe representar
una entidad y las entidades deben ser nicas, por lo que se debe establecer un atributo o
columna identifique de forma nica cada registro de la tabla, esto se hace estableciendo una
llave primaria o clave principal.
De la misma de manera que un contribuyente tiene un nmero de identificacin tributaria, de

la misma manera que un estudiante que lo nmero de carnet nico, igual un vehculo tiene la
identificacin parte del nmero de placa, de esa misma manera todo en otras tablas deben de
contar con una columna identifique de manera nica cada fila de la tabla.
Repetimos, esto se logra estableciendo una llave primaria.

Pgina 43 de 59

Si observamos la figura de nuestro ejemplo la llave primaria en este caso ser el cdigo, pero
la primera regla de normalizacin tambin dicen que los atributos de una tabla deben de ser
atmicos, esto quiere decir que un atributo debe de ser indivisible.
En nuestro ejemplo tengo el atributo nombre, pero en este caso existen nombres que se
componen de dos partes, por lo que en mi ejemplo el atributo no se puede considerar para
atmico ya que puede subdividirse e imprime el nombre segundo nombre, igual con los
apellidos, primer apellido segundo apellido, las direcciones estn divididas en nmeros, y
calles, avenidas, el nmero de casas. Por lo que direccin todava se puede subdividir en
diferentes atributos. En este caso entonces no podemos considerar atmicos a los atributos
que acabo de mencionar.
La primera regla de normalizacin tambin dice que el orden de los datos no debe ser
relevante por lo tanto con Juan Elizandro que est como primer dato podra muy bien estar
cmodo si hago datos o como ltimo dato, ya que el orden del ser irrelevante. Lo mismo
ocurre con los atributos, por ejemplo nombre podra estar como segundo atributo de la tabla o
como ltimo, entonces la posicin en la que estn los atributos no debe ser relevante

Pgina 44 de 59
Repetimos, esto se logra estableciendo una llave primaria.
4.3 Dependencias funcionales

Pgina 45 de 59

Hay veces en que los atributos estn relacionados entre s de manera ms especfica que la
de pertenecer a una misma relacin. Hay veces en que es posible determinar que un atributo
depende de otro funcionalmente.
Las dependencias funcionales son restricciones de integridad sobre los datos. Conocer las
dependencias funcionales en el momento del diseo de la base de datos permite crear
mecanismos para evitar la redundancia (y los potenciales problemas de integridad que eso
conlleva) y mejorar la eficiencia.
Por ejemplo, sea la siguiente relacin: Vehculo (serie, nombre, motor, carrocera, peso,
eficiencia). Aqu, serie es la llave. Por ende, hay solo un [modelo de] motor por serie, slo una
[forma de] carrocera por serie, slo un peso por serie y slo una eficiencia [energtica] por
serie: nombre = nombre (serie), motor = motor (serie), etctera. O sea, serie nombre,
motor, carrocera, peso, eficiencia (la relacin es funcin de su llave; slo hay una tupla por
llave).
Otra observacin, que requiere mucho ms conocimiento del problema, nos indica que la
eficiencia energtica del vehculo es una funcin del motor, la carrocera y el peso.
Considerando esto, tenemos que motor, carrocera, peso eficiencia. Por qu? La eficiencia
energtica consiste en la distancia que puede recorrer un vehculo por litro, a una velocidad
moderadamente alta. La potencia del vehculo reside en el motor: el modelo de motor indica la
fuerza que imprime el vehculo. Sin embargo, esta fuerza es contrarrestada por el roce
aerodinmico del vehculo, que es una funcin del roce viscoso del aire (es un dato fjo) y de
la forma de la carrocera. Y el peso entrega la masa del vehculo (masa = 9, 8m/s 2 peso). Si
se divide la fuerza resultante del vehculo por la masa, se obtiene la aceleracin (y en un
equilibrio de velocidades se obtiene la eficiencia). Luego, existe una funcin tal que eficiencia
= eficiencia (motor, carrocera, peso).
Cmo obtener las dependencias funcionales?
La mejor manera de obtenerlas es a travs del conocimiento del problema. Es lo ms
disponible en la fase de diseo de una base de datos. Sin embargo, esto puede tornarse
bastante difcil, como en el caso del vehculo (honestamente, esto puede ocurrir cuando la
base de datos modela conocimiento tcnico, que escapa al sentido comn).
Otra manera, relacionada con el ejemplo anterior, es comprobar dependencias funcionales
sobre una gran poblacin de datos usando la definicin.

Pgina 46 de 59
4.4 Segunda forma normal

La segunda forma normal (2NF) es una forma normal usada en normalizacin de bases de
datos. Una tabla que est en la primera forma normal (1NF) debe satisfacer criterios
adicionales para calificar para la segunda forma normal. Especficamente: una tabla 1NF est
en 2NF si y solo si, dada una clave primaria y cualquier atributo que no sea un constituyente
de la clave primaria, el atributo no clave depende de toda la clave primaria en vez de solo de
una parte de ella.
En trminos levemente ms formales: una tabla 1NF est en 2NF si y solo si ninguno de sus
atributos no-principales son funcionalmente dependientes en una parte (subconjunto propio)
de una clave primaria (Un atributo no-principal es uno que no pertenece a ninguna clave
primaria).
Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves
candidatas consistiendo en ms de un atributo), la tabla est automticamente en 2NF.
Ejemplo:
Considere una tabla describiendo las habilidades de los empleados:
Habilidades de los empleados
Empleado Habilidad
Lugar actual de trabajo
Jones
Mecanograf
114 Main Street
a
Jones
Taquigrafa
114 Main Street
Jones
Tallado
114 Main Street
Bravo
Limpieza
ligera
73 Industrial Way
Ellis
Alquimia
73 Industrial Way
Ellis
Malabarismo 73 Industrial Way
Harrison
Limpieza
ligera
73 Industrial Way
La nica clave candidata de la tabla es {Empleado, Habilidad}.

Pgina 47 de 59

El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave
candidata, llamada Empleado. Por lo tanto la tabla no est en 2NF. Observe la redundancia de
la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces
que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way.
Esta redundancia hace a la tabla vulnerable a anomalas de actualizacin:
Por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros
"Mecanografa" y "Taquigrafa" y no actualizar su registro "Tallado". Los datos resultantes
implicaran respuestas contradictorias a la pregunta "Cul es el lugar actual de trabajo de
Jones?".
Un alternativa 2NF a este diseo representara la misma informacin en dos tablas:
Empleados
Empleado Lugar actual de trabajo
Jones
114 Main Street
Bravo
73 Industrial Way
Ellis
73 Industrial Way
Harrison 73 Industrial Way

Empleado Habilidad
Jones
Mecanografa
Jones
Taquigrafa
Jones
Tallado
Bravo
Limpieza ligera
Ellis
Alquimia
Ellis
Malabarismo
Harrison Limpieza ligera

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 2NF.
Sin embargo, no todas las tablas 2NF estn libres de anomalas de actualizacin. Un ejemplo
de una tabla 2NF que sufre de anomalas de actualizacin es:

Pgina 48 de 59
Aunque el Ganador y la Fecha de nacimiento del ganador estn determinadas por una clave
completa {Torneo, Ao} y no son partes de ella, particularmente las combinaciones Ganador /
Fecha de nacimiento del ganador son mostradas redundantemente en mltiples registros.
Este problema es tratado por la tercera forma normal (3NF).
2NF y las claves candidatas

Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria est
tpicamente, pero no siempre, en 2NF. Adems de la clave principal, la tabla puede contener
otras claves candidatas; es necesario establecer que ningn atributo no-principal tienen
dependencias de clave parciales en cualesquiera de estas claves candidatas.
Las mltiples claves candidatas ocurren en la siguiente tabla:
Aun si el diseador ha especificado la clave principal como {Nombre completo del modelo}, la
tabla no est en 2NF. {Fabricante, Modelo} es tambin una clave candidata, y Pas del
fabricante es dependiente en un subconjunto apropiado de l: Fabricante.

Pgina 49 de 59
4.5 Tercera forma normal

La tercera forma normal (3NF) es una forma normal usada en la normalizacin de bases de
datos. La 3NF fue definida originalmente por E.F. Codd1 en 1971. La definicin de Codd indica
que una tabla est en 3NF si y solo si las dos condiciones siguientes se:
La tabla est en la segunda forma normal (2NF)
Ningn atributo no-primario de la tabla es dependiente transitivamente de una clave

primaria
Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata. Una

dependencia transitiva es una dependencia funcional X Z en la cual Z no es
inmediatamente dependiente de X, pero s de un tercer conjunto de atributos Y, que a su vez
depende de X. Es decir, X Z por virtud de X Y e Y Z.
Una formulacin alternativa de la definicin de Codd, dada por Carlo Zaniolo2 en 1982, es
sta: Una tabla est en 3NF si y solo si, para cada una de sus dependencias funcionales X
A, por lo menos una de las condiciones siguientes se mantiene:
X contiene A,
X es una superclave,
A es un atributo primario (es decir, A est contenido dentro de una clave candidata)
La definicin de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la 3NF y
la ms rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente elimina la
tercera alternativa ("A es un atributo primario").
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:

Pgina 50 de 59

La nica clave candidata es {Torneo, Ao}. La violacin de la 3NF ocurre porque el atributo no
primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Ao}
va el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es
funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lgicas,
pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de
nacimiento en diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:
Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 3NF.
La mayora de las tablas 3NF estn libres anomalas de actualizacin, insercin, y borrado.
Ciertos tipos de tablas 3NF, que en la prctica raramente se encuentran, son afectadas por
tales anomalas; stas son tablas que no satisfacen la forma normal de Boyce-Codd (BCNF)
o, si satisfacen la BCNF, son insuficientes para satisfacer las formas normales ms altas 4NF
o 5NF.
4.6 Forma normal Boyce-Codd.

La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalizacin
de bases de datos. Es una versin ligeramente ms fuerte de la Tercera forma normal (3FN).
La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no
triviales de los atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN,
todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa
excepto de la clave (excluyendo dependencias triviales, como). Se dice que una tabla est en
FNBC si y solo si est en 3FN y cada dependencia funcional no trivial tiene una clave

Pgina 51 de 59

candidata como determinante. En trminos menos formales, una tabla est en FNBC si est
en 3FN y los nicos determinantes son claves candidatas.
Consideremos una empresa donde un trabajador puede trabajar en varios departamentos. En
cada departamento hay varios responsables, pero cada trabajador slo tiene asignado uno.
Tendramos una tabla con las columnas:
IDTrabajador, IDDepartamento, IDResponsable
La nica clave candidata es IDTrabajador (que ser por tanto la clave primaria). Si aadimos
la limitacin de que el responsable slo puede serlo de un departamento, este detalle produce
una dependencia funcional ya que:
Responsable Departamento
Por lo tanto hemos encontrado un determinante (IDResponsable) que sin embargo no es clave
candidata. Por ello, esta tabla no est en FNBC. En este caso la redundancia ocurre por mala
seleccin de clave. La repeticin del par [IDDepartamento + IDResponsable] es innecesaria y
evitable.
Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un
ejemplo de tal tabla es (teniendo en cuenta que cada estudiante puede tener ms de un tutor):

Pgina 52 de 59

El propsito de la tabla es mostrar qu tutores estn asignados a qu estudiantes. Las claves
candidatas de la tabla son:
{ID Tutor, ID Estudiante}
{Nmero de seguro social del tutor, ID Estudiante}
Una forma sencilla de comprobar si una relacin se encuentra en FNBC consiste en

comprobar, adems de que est en 3FN, lo siguiente:
Si no existen claves candidatas compuestas (con varios atributos), est en FNBC.
Si existen varias claves candidatas compuestas y stas tienen un elemento comn, no

est en FNBC.
En la tabla de ejemplo anterior existen dos claves candidatas y ambas comparten el atributo
ID Estudiante, por lo tanto no est en FNBC.
4.7 Algoritmos de descomposicin

Algoritmo de descomposicin 3FN tambin se denomina algoritmo de sntesis de 3FN, ya que
toma un conjunto de dependencias y aade los esquemas uno a uno, en lugar de
descomponer el esquema inicial de manera repetida.
Algoritmo de descomposicin FNBC, Recibe como argumentos:
1. El conjunto de dependencias funcionales (DF)
2. La relacin original (r)* calculamos f+ * si el esquema no est en FNBC, usamos la primera
DEP funcional de DF no trivial que cumpla que la parte izquierda no sea clave candidata.*
dividimos el esquema r en dos: por un lado creamos un esquema cuyos atributos sean los de
la dependencia funcional y le aadimos aquellas dependencias funcionales de f+ que slo
involucren a esos atributos.* y por otro lado creamos otro esquema cuyos atributos son todos
los de la relacin.
R, menos los de la parte derecha de la dependencia funcional por la que estamos
descomponiendo, y le aadimos aquellas dependencias funcionales de f+ que solo involucren
a atributos de este segundo subesquema.*

Pgina 53 de 59

El proceso es recursivo hasta que todos los esquemas estn en fnbc.atributos raros se dice
que un atributo de una dependencia funcional es raro si se puede eliminar sin modificar el
cierre del conjunto de dependencias funcionales.axiomas de armstrong.
Las dependencias funcionales verifican una serie de propiedades denominadas axiomas de
armstrong: reflexividad. A partir de cualquier atributo o conjunto de atributos siempre puede
deducirse l mismo. Dependencia trivial: x -> x. Aumentatividad. Si x -> y entonces x+z -> y.
As se puede aumentar trivialmente el antecedente de una dependencia.
4.8 Formas normales superiores

Puede que en algunos casos el empleo de las dependencias funcionales para la
descomposicin de los esquemas no sea suficiente para evitar la repeticin innecesaria de
informacin. Considrese una ligera variacin de la definicin del conjunto de entidades
empleado en la que se permite que los empleados tengan varios nmeros de telfono, alguno
de los cuales puede ser compartido entre varios empleados.
Entonces, numero_telefono ser un atributo multivalorado y, de acuerdo con las reglas para la
generacin de esquema a partir de los diseos E-R, habr dos esquemas, uno por cada uno
de los atributos multivalorados numero_telefono y nombre_subordinado:
(id_empleado,nombre_subordinado)(id_empleado,numero_telefono)
Si se combinan estos esquemas para obtener
(id_empleado,nombre_subordinado,numero_telefono)
Se descubre que el resultado se halla en la FNBC, ya que solo se cumplen dependencias
funcionales no triviales. En consecuencia, se puede pensar que ese tipo de combinacin es
una buena idea. Sin embargo se trata de una mala idea, como puede verse si se considera el
ejemplo de un empleado con dos subordinados y dos nmeros de telfono. Por ejemplo, sea
el empleado con id_empleado 9999999999 que tiene dos subordinados llamados David y
Guillermo y dos nmeros de telfono, 512555123 y 512555432. En el esquema combinado
hay que repetir los nmeros de telfono una vez por cada subordinado:

Pgina 54 de 59

(9999999999, David, 512555123)
(9999999999, David, 512555432)
(9999999999, Andres, 512555123)
(9999999999, Andres, 512555432)
Si no se repitieran los nmeros de telfonos y solo se almacenaran la primera y la ltima tupla,

se habran guardado el nombre de los subordinados y los nmeros de telfono, pero las tuplas
resultantes implicaran que David correspondera al 512555123 y que Andrs correspondera
al 512555432. Como sabemos, esto es incorrecto.
Debido a que las formas normales basadas en las dependencias funcionales no son
suficientes para tratar con sustituciones como esta, se han definido otras dependencias y
formas normales.
4.9 Integridad de las bases de datos

Integridad de las Bases de Datos, la integridad en una base de datos es la correccin y
exactitud de la informacin contenida. Adems de conservar la seguridad en un sistema de
bases de datos que permite el acceso a mltiples usuarios en tiempos paralelos.
Condiciones de la Integridad
Las condiciones que garantizan la integridad de los datos pueden ser de dos tipos:
Las restricciones de integridad de usuario: son condiciones especficas de una base de datos
concreta; son las que se deben cumplir en una base de datos articular con unos usuarios
concretos, pero que no son necesariamente relevantes en otra Base de Datos.
Las reglas de integridad de modelo: son condiciones propias de un modelo de datos, y se
deben cumplir en toda base de datos que siga dicho modelo.
Los SGBD deben proporcionar la forma de definir las restricciones de integridad de usuario de
una base de datos y una vez definida, debe velar por su cumplimiento. Las reglas de

Pgina 55 de 59

integridad del modelo, en cambio, no se deben definir para cada base de datos concreta,
porque se consideran preestablecidas para todas las base de datos de un modelo. Un SGBD
de un modelo determinado debe velar por el cumplimiento de las reglas de integridad
preestablecidas por su modelo.
Reglas de Integridad
Regla de integridad de unicidad de la clave primaria
La regla de integridad de unicidad est relacionada con la definicin de clave primaria que
establece que toda clave primaria que se elija para una relacin no debe tener valores
repetidos por lo que el conjunto de atributos CP es la clave primaria de una relacin R,
entonces la extensin de R no puede tener en ningn momento dos tuplas con la misma
combinacin de valores para los atributos de CP.
Regla de integridad de entidad de la clave primaria
La regla de integridad de entidad de la clave primaria dispone que los atributos de la clave
primaria de una relacin no pueden tener valores nulos. Esta regla es necesaria para que los
valores de las claves primarias puedan identificar las tuplas individuales de las relaciones. Si
las claves primarias tuviesen valores nulos, es posible que algunas tuplas no se pudieran
distinguir. Un SGBD relacional tendr que garantizar el cumplimiento de esta regla de
integridad en todas las inserciones y en todas las modificaciones que afecten a atributos que
pertenecen a la clave primaria de la relacin.
Regla de integridad referencial
La regla de integridad referencial est relacionada con el concepto de clave fornea, lo que
determina que todos los valores que toma una clave fornea deben ser valores nulos o
valores que existen en la clave primaria que referencia. La necesidad de esta regla es debido
a que las claves forneas tienen por objetivo establecer una conexin con la clave primaria
que referencian. Si un valor de una clave fornea no estuviese presente.
Restriccin
La restriccin en caso de borrado, consiste en no permitir borrar una tupla si tiene una clave
primaria referenciada por alguna clave fornea y la restriccin en caso de modificacin
consiste en no permitir modificar ningn atributo de la clave primaria de una tupla si tiene una
clave primaria referenciada por alguna clave fornea.

Pgina 56 de 59

Actualizacin en cascada
La actualizacin en cascada consiste en permitir la operacin de actualizacin de la tupla, y en
efectuar operaciones compensatorias que propaguen en cascada la actualizacin a las tuplas
que la referenciaban; se acta de este modo para mantener la integridad referencial. La
actualizacin en cascada en caso de borrado consiste en permitir el borrado de una tupla t
que tiene una clave primaria referenciada, y borrar tambin todas las tuplas que referencian t y
la actualizacin en cascada en caso de modificacin consiste en permitir la modificacin de
atributos de la clave primaria de una tupla t que tiene una clave primaria referenciada, y
modificar del mismo modo todas las tuplas que referencian t.
Anulacin
La anulacin consiste en permitir la operacin de actualizacin de la tupla y en efectuar
operaciones compensatorias que pongan valores nulos a los atributos de la clave fornea de
las tuplas que la referencian; esta accin se lleva a cabo para mantener la integridad
referencial. Los SGBD relacionales permiten establecer que un determinado atributo de una
relacin no admite valores nulos, slo se puede aplicar la poltica de anulacin si los atributos
de la clave fornea s los admiten. Ms concretamente, la anulacin en caso de borrado
consiste en permitir el borrado de una tupla t que tiene una clave referenciada y, adems,
modificar todas las tuplas que referencian t, de modo que los atributos de la clave fornea
correspondiente tomen valores nulos y la anulacin en caso de modificacin consiste en
permitir la modificacin de atributos de la clave primaria de una tupla t que tiene una clave
referenciada y, adems, modificar todas las tuplas que referencian t, de modo que los atributos
de la clave fornea correspondiente tomen valores nulos.
Regla de integridad de dominio
La regla de integridad de dominio est relacionada con la nocin de dominio. Esta regla
establece dos condiciones.
La primera condicin consiste en que un valor no nulo de un atributo Ai debe
pertenecer al dominio del atributo Ai; es decir, debe pertenecer a dominio(Ai). Esta
condicin implica que todos los valores no nulos que contiene la base de datos para
un determinado atributo deben ser del dominio declarado para dicho atributo.
La segunda condicin sirve para establecer que los operadores que pueden
aplicarse sobre los valores dependen de los dominios de estos valores; es decir, un

Pgina 57 de 59

operador determinado slo se puede aplicar sobre valores que tengan dominios que le
sean adecuados.

Pgina 58 de 59
REFERENCIAS
Bibliogrficas
Electrnicas
http://orlandotlilayatzi.wikispaces.com/UNIDAD+1
http://www.estructurayprogramacion.com/materias/fundamentos-de-basede-datos/t%C3%B3picos-selectos-de-bases-de-datos/
http://www.marcoteorico.com/curso/31/fundamentos-de-bases-de-datos#423
http://www.estructurayprogramacion.com/materias/fundamentos-de-basede-datos/

Pgina 59 de 59

Antologia 4A JEMIMA

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Antologia 4A JEMIMA

Diunggah oleh

Hak Cipta:

Format Tersedia

INSTITUTO TECNOLGICO SUPERIOR DE TEPEACA

INGENIERA EN SISTEMAS COMPUTACIONALES

CANO VAZQUEZ JEMIMA

20 DE MARZO DE 2014 ( Debe ir subrayado)

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia

Objetivo de las Bases de Datos...................................................................4

reas de Aplicacin de los Sistemas de Bases de datos............................5

Arquitectura del Sistema Gestor de Bases de datos...................................8

UNIDAD 2. DISEO DE BASES DE DATOS Y EL MODELO E-R........................17

INGENIERA DE SOFTWARE / AVANCE No. 1

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

UNIDAD 1. SISTEMAS GESTORES DE BASES DE DATOS.

Objetivo de las Bases de Datos.

Un sistema gestor de bases de datos (SGBD) consiste en una coleccin de datos

Una coleccin interrelacionada de datos, almacenados en un conjunto sin

Conjunto de datos organizados con caractersticas afines entre s, que identifican a un

Conjunto auto descriptivo de registros integrados; auto descriptivo ya que puede

Los componentes de una base de datos son:

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Informtico: son los profesionales que definen y preparan la base de datos.

reas de Aplicacin de los Sistemas de Bases de datos.

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Bajo la estructura de la base de datos se encuentra el modelo de datos: una coleccin de

Rectngulos, que representan conjuntos de entidades.

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Arquitectura del Sistema Gestor de Bases de datos.

La mayora de usuarios de un sistema de bases de datos no estn situados actualmente junto

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Un objetivo principal de un sistema de bases de datos es recuperar informacin y almacenar

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Los usuarios sofisticados.

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Supervisin de los trabajos que se ejecuten en la base de datos y asegurarse de que

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

La recuperacin de informacin almacenada en la base de datos.

LMDs procedimentales. Requieren que el usuario especifique qu datos se necesitan y

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

LMDs declarativos (tambin conocidos como LMDs no procedimentales). Requieren

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

UNIDAD 2. DISEO DE BASES DE DATOS Y EL MODELO E-R.

2.2 Modelo Entidad-Relacin.

Creatividad Tecnolgica Y Calidad Educativa, Pilares Para La Excelencia Humana

INGENIERA DE SOFTWARE / AVANCE No. 1

Atributos compuestos: Un atributo compuesto, es un atributo que puede ser

Atributos monovalorados y multivalorados.

Llave o clave de la relacin: Es el identificador nico de cada tupla.