López Martínez Germán

307INFO
1.1 C y 1.2 A,B

C) Elabora un modelo entidad relación

Entidad
Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se diferencia
unívocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad.

Ejemplos:

• Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).

• Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos diferentes, por
ejemplo, el número de bastidor)

• Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).

Una entidad puede ser un objeto con existencia física como: una persona, un animal, una casa, etc. (entidad
concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un
nombre,etc. (entidad abstracta).

Una entidad está descrita y se representa por sus características o atributos. Por ejemplo, la entidad Persona
puede llevar consigo las características: Nombre, Apellido, Género, Estatura, Peso, Fecha de nacimiento, etc..

Atributos
Los atributos son las caracteristicas que definen o identifican a una entidad, estas pueden ser muchas, y solo
el diseñador utiliza o implementa las que considere mas relevantes. Los atributos son las propiedades que
describen a cada entidad en un conjunto de entidades.

El atrubuti puede hacer 1 de tres cosas:

o Identificar

o Relacionar

o Describir

Un conjunto de entidades dentro de una entidad, tiene valores específicos asignados para cada uno de sus
atributos, de esta forma, es posible su identificación unívoca.

Ejemplos:

A la colección de entidades Alumnos, con el siguiente conjunto de atributos en común, (id, nombre, edad,
semestre), pertenecen las entidades:

• (1, Sofia, 38 años, 2)

• (2, Josefa, 19 años, 5)

• (3, Carlos, 20 años, 2)

• ...

Cada una de las entidades pertenecientes a este conjunto se diferencia de las demás por el valor de sus
atributos. Nótese que dos o más entidades diferentes pueden tener los mismos valores para algunos de sus
atributos, pero nunca para todos.
 López Martínez Germán
307INFO
1.1 C y 1.2 A,B

En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad
de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su número de id.

Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que será almacenado o
a restricciones en los valores que el atributo puede tomar (Cadenas de caracteres, números, solo dos letras,
solo números mayores que cero, solo números enteros...).

Cuando una entidad no tiene un valor para un atributo dado, este toma el valor nulo, bien sea que no se
conoce, que no existe o que no se sabe nada al respecto del mismo.

Ejemplos de entidades con sus atributos

En el diseño se pueden considerar 3 categorías de atributos

• Simples o compuestos: ya sea que el atributo sea un todo o bien este compuesto

o Color es simple, toma valores rojo, azul, etc

o Nombre es compuesto, contiene nombre de pila, apellido materno, apellido materno.

• Con valores simples o multivaluados: en base a si consisten de un solo valor o un conjunto de valores.

o Telefono o Teléfonos

• Derivados: que se pueden calcular en base a otros atributos

NOTA: en la práctica es mejor considerar "siempre" a todos los atributos

como simples y con valores simples

Claridad del las relaciones

Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la correspondencia de
cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada.

Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de

cardinalidades puede ser:

• Uno a Uno: Una entidad de A se relaciona únicamente con una entidad en B y viceversa (ejemplo relación
vehículo - matrícula: cada vehículo tiene una única matrícula, y cada matrícula está asociada a un único
vehículo).

• Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se
relaciona con una única entidad en A (ejemplo vendedor - ventas).

• Varios a Uno: Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B
se puede relacionar con 0 o muchas entidades en A (ejemplo empleado-centro de trabajo).

• Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa (ejemplo
asociaciones- ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociación, y cada
ciudadano puede pertenercer a muchas asociaciones distintas)
 López Martínez Germán
307INFO
1.1 C y 1.2 A,B

1.2 Diseña la estructura lógica de la BD mediante la

normalización de esquemas
A) Elaboración del modelo nacional basado en el modelo entidad
relación
Tablas y tuplas
TUPLAS

ES UN CONJUNTO DE NOMBRES DE ATRIBUTOS RELACIONADOS A PARES CON LOS DOMINIOS DE

DICHOS ATRIBUTOS. OPERADORES: ASIGNAR,CONSULTAR. (ASIGNAR(T,DIRECCION,”COLON 4”);
CONSULTAR(T,NOMBRE)=”PEPA GÓMEZ” ).

TABLAS

INSERT INTO tabla [ (comalista_columna) ] { DEFAULT VALUES | VALUES (comalista_átomos) |

expresión_tabla }

comalista_columna: SI NO SE INCLUYE SE DEBERAN REALIZAR INSERCIONES DE FILAS COMPLETAS

DE LA TABLA.

DEFAULT VALUES: SE INSERTARAN LOS VALORES POR DEFECTO O EL VALOR NULO.

VALUES(comalista_átomos): DEBE EXISTIR CORRESPONDENCIA ENTRE LOS ATOMOS Y LAS

COLUMNAS.

expresión_tabla: SE INSERTARAN LAS FILAS DEVUELTAS EN LA EJECUCION EN CONCORDANCIA CON

LA LISTA DE COLUMNAS O CON LA DEFINICION DE LAS COLUMNAS EN LA TABLA.

EJEMPLO: INSERT INTO Proveedor(dni, nombre, dir) VALUES (12345678,'Juan Pérez','Cuenca 25')

Claves primarias y ajenas

La clave principal de una tabla consta de uno o varios campos que identifican inequívocamente cada fila
almacenada en la tabla. Normalmente, hay un número de identificación exclusivo, como un número de Id., un
número de serie o un código que sirve de clave principal. Por ejemplo, en una tabla Clientes, cada cliente
podría tener un número de Id. de cliente distinto. El campo Id. de cliente sería, en ese caso, la clave principal
de la tabla.

Un buen candidato para una clave principal debe tener varias características. En primer lugar, debe identificar
inequívocamente cada fila. En segundo lugar, nunca debe estar vacío ni ser nulo (siempre debe contener un
valor). En tercer lugar, casi nunca (o, preferiblemente, nunca) debe cambiar. Access utiliza campos de clave
principal para reunir rápidamente los datos de varias tablas.

Siempre debe especificar una clave principal para una tabla. Access crea automáticamente un índice para la
clave principal, que permite agilizar las consultas y otras operaciones. Access comprueba también que cada
registro tiene un valor en el campo de clave principal y que éste es siempre distinto.
 López Martínez Germán
307INFO
1.1 C y 1.2 A,B

Reglas de integridad
La integridad en una base de datos se refiere a la corrección y exactitud de la información contenida. Una
base de datos determinada podría estar sujeta a cualquier cantidad de restricciones de integridad (en general)
de una complejidad arbitraria. En la mayoría de los sistemas actuales, la verificación de la integridad se realiza
mediante códigos de procedimientos escritos por los usuarios.

Algunos ejemplos de restricciones de integridad serían:

• Los dueños de cuentas de ahorro no pueden solicitar un monto mayor de dinero del que hayan juntado hasta
la fecha.

• Para que un cliente sea considerado especial, deberá tener un mínimo de USD 1.000 en compras promedio
al año.

La Integridad es el término utilizado para decir que la información almacenada tiene calidad. El DBMS tiene
que asegurar que los datos se almacenan de acuerdo a las políticas previamente determinadas por el DBA.
En otras palabras, el DBMS debe principalmente, a este respecto, comprobar las restricciones de integridad,
controlar la correcta ejecución de las actualizaciones y recuperar la base de datos en caso de pérdida.

Un control de integridad o restricción es aquel que nos permite definir con precisión el rango de valores
válidos para un elemento y/o las operaciones que serán consideraciones válidas en la relación de tales
elementos.

Transformación de entidades
Empezaremos el proceso transformando todas las entidades de un modelo ER adecuadamente. Cada entidad
del modelo ER se transforma en una relación del modelo relacional. Los atributos de la entidad serán atributos
de la relación y, de forma análoga, la clave primaria de la entidad será la clave primaria de la relación.

Ejemplo de transformación de una entidad

Según esto, la entidad de la figura del margen se transforma en la relación que tenemos a continuación.

B) Normalización del modelo racional partiendo de una relación

universal
Primera forma normal
Una tabla está en Primera Forma Normal si:

• Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles,
mínimos.

• La tabla contiene una clave primaria unica.

• La clave primaria no contiene atributos nulos.

• No debe de existir variación en el número de columnas.

• Los Campos no clave deben identificarse por la clave (Dependencia Funcional)

• Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos
cambian de orden no deben cambiar sus significados
 López Martínez Germán
307INFO
1.1 C y 1.2 A,B

Una tabla no puede tener múltiples valores en cada columna. Los datos son atómicos. (Si a cada valor de X le
pertenece un valor de Y y viceversa)

Esta forma normal elimina los valores repetidos dentro de una BD

Segunda forma normal

Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de
ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias
parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).

En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia
completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A
de X significa que la dependencia no es mantenida, esto es que . Una dependencia funcional es una
dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la dependencia todavía se
mantiene, esto es .

Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto

sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente
dependiente dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la
dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado
que DNI NOMBRE_EMPLEADO mantiene la dependencia.

Tercer forma normal

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los
atributos que no son clave.

Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una
dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R,
donde se mantiene X->Z y Z->Y

Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente

figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque
las dependencias SSN?DNUMBER y DNUMBER?DMGRSSN son mantenidas, y DNUMBER no es un
subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN
sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.

Formalmente, un esquema de relacion R está en 3 Forma Normal Elmasri-Navathe, si para toda dependencia
funcional , se cumple al menos una de las siguientes condiciones:

1. X es superllave o clave.

2. A es atributo primo de R; esto es, si es miembro de alguna clave en R.

Además el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.

Forma norman de Boyce-Codd

Es una forma normal utilizada en la normalización de bases de datos. Es una versión ligeramente más 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 candidata como determinante. En terminos menos
formales, una tabla está en FNBC si está en 3FN y los únicos determinantes son claves candidatas.
 López Martínez Germán
307INFO
1.1 C y 1.2 A,B

Ejemplo

La cuestión es que un trabajador o trabajadora puede trabajar en varios departamentos. En dicho

departamento hay varios responsables, pero cada trabajador sólo tiene asignado uno. El detalle importante
que no se ha tenido en cuenta, es que el o la responsable sólo puede ser responsable en un departamento.
Este detalle último produce una dependencia funcional ya que: Responsable? Departamento Por lo tanto
hemos encontrado un determinante que no es clave candidata. No está por tanto en FNBC. En este caso la
redundancia ocurre por mala selección de clave. La redundancia del departamento es completamente
evitable.

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 más de un tutor):

El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las claves candidatas de la
tabla son:

• {ID Tutor, ID Estudiante}

• {Número de seguro social del tutor, ID Estudiante}

Por lo tanto los tres atributos de la tabla son atributos primarios, es decir, los tres atributos pertenecen a las
claves candidatas.

Recuerde que la 2NF prohíbe dependencias funcionales parciales de atributos no-primarios en las claves
candidatas, y la 3NF prohíbe dependencias funcionales transitivas de atributos no-primarios en claves
candidatas. Dado que la tabla de arriba carece de cualquier atributo no-primario, está en 2NF y 3NF.

La FNBC es más rigurosa que la 3NF en que no permite ninguna dependencia funcional en la cual el conjunto
determinante de atributos no sea una clave candidato (o superconjunto de eso). La dependencia de ID Tutor
en Número de seguro social del tutor es ese tipo de dependencia. Por consiguiente, la tabla de arriba no está
en FNBC

Cualquier tabla que sea insuficiente en FNBC será vulnerable a inconsistencias lógicas. En la tabla de arriba
podía ser representada una combinación inconsistente de ID Tutor y Número de seguro social del tutor.

En este caso, corregir el problema sería una simple cuestión de usar solo un esquema de identificación para
los tutores: o el ID, o el número del seguro social, pero no ambos.

Otra formulación

Una forma sencilla de comprobar si una relación se encuentra en FNBC consiste en comprobar, además de
que esté en 3FN, lo siguiente:

• (1) Si no existen claves candidatas compuestas (con varios atributos), está en FNBC.

• (2) Si existen varias claves candidatas compuestas y éstas tienen un elemento común, no está en FNBC.