Modelo Entidad Relación E-R

"Modelo de datos basado en una percepción del mundo real que consiste en un conjunto
de objetos básicos llamados entidades y relaciones entre estos objetos" [Kor98]. Describe
los datos en los niveles conceptual y de vista.

El modelo E-R, tiene su implementación grafica en el Diagrama Entidad-Relación.

Componentes y Diagrama E-R     Entidad: Representa un objeto que tiene vida propia en el
sistema que se está modelando, tanto tangible como intangibles. Ejemplo: cliente,
producto, estudiante, vacación.

Conjunto de entidades: Grupo (conjunto) de entidades del mismo tipo. Ejemplo: Todos los
estudiantes de un curso, representan el conjunto de entidades estudiante.

Relación: Asociación o vinculación entre dos o más entidades. Ejemplo: La relación

comprar entre las entidades cliente y producto. Generalmente representa acciones entre
las entidades.

Conjunto de relaciones: Son relaciones del mismo tipo.

Atributos: Características o propiedades asociadas al conjunto de entidades o relaciones y

que toman valor en una entidad en particular. Ejemplo: nombre, cédula, teléfono.
Los posibles valores puede tomar un atributo para un conjunto de entidades se denomina
dominio.

Los atributos se pueden clasificar en:

- Simples o atómicos: Son aquellos que no contienen otros atributos

- Compuestos: Son los que incluyen otros atributos simples.. Ejemplo: dirección (Se puede
dividir en calle, número, ciudad).
- Monovalorados o Univalorados: Atributo que toma un solo valor, para una entidad en
particular.
- Multivalorados: Atributo que para una misma entidad puede tomar muchos valores.
- Derivados o calculados: Son aquellos atributos cuyos valores se pueden conseguir con
operaciones sobre valores de otros atributos.
- Nulos: Son aquellos atributos para los cuales en algún momento no existe o no se conoce
su valor. 

Diagrama Entidad - Relación.

Es la representación gráfica del Modelo Entidad-Relación y permite ilustrar la estructura

de la base de datos del negocio modelado.
Escribe Johnson "los diagramas ER constituyen una notación para documentar un diseño
tentativo de bases de datos. Los analistas los utilizan para facilitar el proceso de diseño"
[Joh00].

Está compuesto por los siguientes elementos.

Rectángulo que representa un conjunto de entidades.

    Elipse que representa los atributos de cada entidad.     Rombos que representan
conjuntos de relaciones.       Estos elementos se unen a través de líneas para formar así el
diagrama.

Ejemplo:
Dependiendo del tipo de atributo representan en forma diferente:
- Simples y monovalorados: Se simbolizan con una elipse sencilla .
- Compuestos: Se representan por una elipse de la cual salen otras elipses con los atributos
simples.
- Multivalorados: Se representan con una elipse doble.
- Derivados: Se representan con una elipse punteada.

Otra forma de representar los conjuntos de entidades y sus atributos consiste mostrar los
atributos en forma de lista dentro del rectángulo:

El proceso de normalización de bases de datos relacionales

La normalización de bases de datos relacionales toma un esquema relacional y le aplica un

conjunto de técnicas para producir un nuevo esquema que representa la misma información pero
contiene menos redundancias y evita posibles anomalías en las inserciones, actualizaciones y
borrados.

Breve recordatorio del modelo (formal) relacional

El modelo relacional de bases de datos se basa en un modelo formal especificado de acuerdo a la

teoría de conjuntos. Una base de datos relacional puede considerarse como un conjunto de
relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la relación, que se define por
una serie de atributos Ai.
Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de entidad es
una restricción que nos indica que cada entidad representada por una tupla tiene que ser
diferente de las demás en su relación, es decir, debe haber algunos atributos cuyos valores
identifiquen unívocamente las tuplas. La integridad referencial indica que una clave ajena solo
debe contener valores que o bien sean nulos, o bien existan en la relación referenciada por la
clave ajena.

El proceso de normalización

El proceso de normalización consiste en comprobar en secuencia si el esquema original está en

1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.

Un ejemplo completo

Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado, de
modo que las condiciones salariales están determinadas por el puesto. Se ha creado el siguiente
esquema relacional

EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.

Primera forma normal (1FN)

Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que
el atributo emails puede contener más de un valor, por lo que viola 1FN.

En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de
1FN, tenemos dos opciones.

Solución 1: duplicar los registros con valores repetidos

En general, esta solución pasa por sustituir R por una nueva relación modificada R', en la cual:
 * El atributo M que violaba 1FN se elimina.

* Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si
R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K]. En otras palabras, para
una tupla con n valores duplicados en M, en la nueva relación habrá n tuplas, que sólo varían en
que cada una de ellas guarda uno de los valores que había en M.

* La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los
valores multivaluados en M.

Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con
clave primaria (nss, email):

Solución 2: separar el atributo que viola 1FN en una tabla

En general, esta solución pasa por:

sustituir R por una nueva relación modificada R' que no contiene el atributo M.

Crear una nueva relación N(K, M'), es decir, una relación con una clave ajena K referenciando R',
junto al atributo M', que es la variante mono-valuada del atributo M.

La nueva relación N tiene como clave (K, M').

Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(b)

y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):

Segunda forma normal (2FN)

Un esquema está en 2FN si:

Está en 1FN.

Todos sus atributos que no son de la clave principal tienen dependencia funcional completa
respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada
atributo no clave se necesita la clave primaria completa, no vale con una subclave.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos.
Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces
también está en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) está en 1FN
(y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo,
tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a).
Las dependencias funcionales que tenemos son las siguientes:

nss->nombre, salario, email

puesto->salario

Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo
que la relación no está en 2FN.
En general, tendremos que observar los atributos no clave que dependan de parte de la clave.

Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con
dependencia incompleta M:

Eliminar de R el atributo M.

Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende,
que llamaremos K'.

La clave primaria de la nueva relación será K'.

Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen
dependencia incompleta:

Y al eliminar de la tabla original estos atributos nos quedaría:

Como vemos, la solución a la que llegamos es la misma que en la otra opción de solución para el
problema de 1FN.

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si:

está en 2FN

y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de
la clave primaria.

Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre
atributos que no estén en la clave.

En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de

dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a
este tipo de dependencias está en separar en una tabla adicional N el/los atributos B, y poner como
clave primaria de N el atributo que define la transitividad A.

Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:

nss->puesto

puesto->salario

Por lo tanto la descomposición sería la siguiente:

En la nueva tabla PUESTOS, la clave sería el puesto, que también queda como clave ajena
referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.

Sistema Gestor de Bases de Datos (SGBD)

Un Sistema Gestor de Bases de Datos (SGBD) o DBMA (DataBase Management System) es

una colección de programas cuyo objetivo es servir de interfaz entre la base de datos, el
usuario y las aplicaciones. Se compone de un lenguaje de definición de datos, de un
lenguaje de manipulación de datos y de un lenguaje de consulta. Un SGBD permiten
definir los datos a distintos niveles de abstracción y manipular dichos datos, garantizando
la seguridad e integridad de los mismos.
Algunos ejemplos de SGBD son Oracle, DB2, PostgreSQL, MySQL, MS SQL Server, etc.

Un SGBD debe permitir:

• Definir una base de datos: especificar tipos, estructuras y restricciones de datos.
• Construir la base de datos: guardar los datos en algún medio controlado por el mismo
SGBD
• Manipular la base de datos: realizar consultas, actualizarla, generar informes.

Las características de un Sistema Gestor de Base de Datos SGBD son:

• Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del
almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos
de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de
abstracción.
• Independencia. La independencia de los datos consiste en la capacidad de modificar el
esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las
aplicaciones que se sirven de ella.
• Redundancia mínima. Un buen diseño de una base de datos logrará evitar la aparición
de información repetida o redundante. De entrada, lo ideal es lograr una redundancia
nula; no obstante, en algunos casos la complejidad de los cálculos hace necesaria la
aparición de redundancias.
• Consistencia. En aquellos casos en los que no se ha logrado esta redundancia nula, será
necesario vigilar que aquella información que aparece repetida se actualice de forma
coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea.
• Seguridad. La información almacenada en una base de datos puede llegar a tener un
gran valor. Los SGBD deben garantizar que esta información se encuentra segurizada
frente a usuarios malintencionados, que intenten leer información privilegiada; frente a
ataques que deseen manipular o destruir la información; o simplemente ante las torpezas
de algún usuario autorizado pero despistado. Normalmente, los SGBD disponen de un
complejo sistema de permisos a usuarios y grupos de usuarios, que permiten otorgar
diversas categorías de permisos.
• Integridad. Se trata de adoptar las medidas necesarias para garantizar la validez de los
datos almacenados. Es decir, se trata de proteger los datos ante fallos de hardware, datos
introducidos por usuarios descuidados, o cualquier otra circunstancia capaz de
corromper la información almacenada.
• Respaldo y recuperación. Los SGBD deben proporcionar una forma eficiente de realizar
copias de respaldo de la información almacenada en ellos, y de restaurar a partir de estas
copias los datos que se hayan podido perder.
• Control de la concurrencia. En la mayoría de entornos (excepto quizás el doméstico), lo
más habitual es que sean muchas las personas que acceden a una base de datos, bien para
recuperar información, bien para almacenarla. Y es también frecuente que dichos accesos
se realicen de forma simultánea. Así pues, un SGBD debe controlar este acceso
concurrente a la información, que podría derivar en inconsistencias.

LIC.GUILLERMO GONZALEZ GALERA

Alumna:

Yamileth amisadai cruz reyes

MATERIA:

Programación con sistemas gestores de base de datos

Tema:

Base de datos

GRUPO:

5103

FECHA:

26/AGOSTO/2010