Base de datos

MODELO ENTIDAD RELACION

 Sistemas de ficheros tradicionales
Sistemas de ficheros tradicionales: cada programa almacenaba y utilizaba sus propios datos de

forma un tanto caótica.

La única ventaja que conlleva esto es que los procesos son independientes, por lo que la

modificación de uno no afecta al resto.

Pero tiene grandes inconvenientes:

1. Datos redundantes. Ya que se repiten continuamente.

2.Coste de almacenamiento elevado. Al almacenarse varias veces el mismo dato en distintas

aplicaciones, se requiere más espacio en los discos.

3. Tiempos de procesamiento elevados. Al no poder optimizar el espacio de almacenamiento.

4. Probabilidad alta de inconsistencia en los datos. Ya que un proceso cambia sus datos y no
el

resto. Por lo que el mismo dato puede tener valores distintos según qué aplicación acceda a él.
5. Difícil modif icación en los datos. Debido a la probabilidad de inconsistencia, cada modif icación

se debe repetir en todas las copias del dato (algo que normalmente es imposible).
 Sistemas de ficheros tradicionales
En la siguiente figura se muestra un sistema de información basado en ficheros. En ella se ve que

la información aparece inconexa y redundante.

 Sistemas de ficheros tradicionales
Se cuenta con dos archivos: CLIENTES y FACTURAS.

El primer archivo tiene los datos básicos de los clientes, mientras que en el segundo se

almacenan las ventas realizadas. Al emitir cada factura se ingresan nuevamente los datos num,

nombre, domicilio.
 Sistemas de base de datos relacional
En este tipo de sistemas los datos se centralizan en una base de datos común a todas las

aplicaciones.

Principales ventajas:

• Menor redundancia. No hace falta tanta repetición de datos. Aunque, sólo los buenos diseños

de datos tienen poca redundancia.

• Menor espacio de almacenamiento. Gracias a una mejor estructuración de los datos.
• Acceso a los datos más ef iciente. La organización de los datos produce un resultado más

óptimo en rendimiento.
• Datos más documentados. Gracias a los metadatos que permiten describir la información

de la base de datos.
• Independencia de los datos y los programas y procesos. Esto permite modif icar los datos

sin modif icar el código de las aplicaciones.

• Integridad de los datos. Mayor dificultad de perder los datos o de realizar incoherencias con

ellos. Mayor seguridad en los datos. Al limitar el acceso a ciertos usuarios.

 Sistemas de base de datos relacional
En este tipo de sistemas los datos se centralizan en una base de datos común a todas las

aplicaciones.

Principales inconvenientes:

Instalación costosa. El control y administración de bases de datos requiere de un software y

hardware potente.
Requiere personal cualif icado. Debido a la dif icultad de manejo de este tipo de sistemas.

Implantación larga y difícil. Debido a los puntos anteriores. La adaptación del personal es mucho

más complicada y lleva bastante tiempo.

 Sistemas de base de datos relacional
Sistema de información basado en bases de datos. La información está relacionada y no es
redundante.
 Modelo de datos.

• En informática, un modelo de datos es un lenguaje utilizado

para la descripción de una base de datos. Con este lenguaje
vamos a poder describir las estructuras de los datos (tipos de
datos y relaciones entre ellos), las restricciones de integridad
(condiciones que deben cumplir los datos, según las
necesidades de nuestro modelo basado en la realidad) y las
operaciones de manipulación de los datos (insertado, borrado,
modificación de datos). Es importante distinguir entre modelo
de datos y esquema.
• La interacción entre los tres modelos es fundamental para
un diseño de calidad:
1.- Se negocia con el usuario el modelo conceptual.
2.- Se pasa el modelo conceptual al modelo lógico, realizando una
serie de transformaciones necesarias para adaptar el lenguaje del
usuario al del gestor de base de datos
3.- Se transforma el modelo lógico en físico, obteniendo de esta
forma la base de datos final.
INFORMATICO
USUARIO MODELO DISEÑADOR DE BBDD
EXPERTO CONCEPTUAL

MODELO LOGICO
DOMINIO
DEL
PROBLE
MA PROGRAMADOR BBDD

BASE DE MODELO FÍSICO

ADMINISTRADOR
DATOS BBDD
• Hemos dicho que un modelo de datos es un lenguaje y por lo
general, presenta dos sublenguajes:
•  Lenguaje de Definición de Datos o DDL (Data Definition
Language), cuya función es describir, de una forma abstracta, las
estructuras de datos y las restricciones de integridad.
•  Lenguaje de Manipulación de Datos o DML (Data
Manipulation Language), que sirven para describir las
operaciones de manipulación de los datos.
 Modelo Entidad/Relación

Las bases de datos son un gran pilar de la programación actual, ya que nos
permiten almacenar y usar de forma rápida y eficiente cantidades ingentes de
datos con cierta facilidad. En la actualidad se usa de forma mayoritaria las
bases de datos relacionales (dominadas por distintos gestores a través del
lenguaje SQL, en gran medida).

El modelo entidad-relación es la mejor forma de representar la estructura de

estas bases de datos relacionales (o de representar sus esquemas).
 ¿Qué es el modelo entidad-relación?
Este modelo es un método del que disponemos para diseñar
estos esquemas que posteriormente debemos de implementar
en un gestor de BBDD (bases de datos). Este modelo se
representa a través de diagramas y está formado por varios
elementos.

Este modelo habitualmente, además de disponer de un diagrama

que ayuda a
entender los datos y como se relacionan entre ellos, debe de ser
completado con un pequeño resumen con la lista de los
atributos y las relaciones de cada elemento.
 Elementos del modelo entidad-
relación
Entidad
Las entidades representan cosas u objetos (ya sean reales o abstractos), que se diferencian claramente
entre sí.

Para poder seguir un ejemplo utilizaremos un taller mecánico, donde se podría crear las siguientes
entidades:

Coches (objeto físico): contiene la información de cada taller.

Empleado (objeto físico): información de los trabajadores.
Cargo del empleado (cosa abstracta): información de la
función del empleado.
Estas entidades se representan en un diagrama con un
rectángulos, como los siguientes.
Elementos del modelo entidad-relación

Atributos

Los atributos definen o identifican las características de entidad (es el contenido de esta entidad).

Cada entidad contiene distintos atributos, que dan información sobre esta entidad. Estos atributos

pueden ser de distintos tipos (numéricos, texto, fecha...).

Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad "Coches", que nos

darán información sobre los coches de nuestro supuesto taller.

Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI del propietario, marca,

modelo y muchos otros que complementen la información de cada coche.

Los atributos se representan como círculos que descienden de una entidad, y no es

necesario representarlos todos, sino los más significativos, como a continuación.

 Elementos del modelo entidad-
relación
En un modelo relacional (ya implementado en una base de datos) una ejemplo de tabla dentro de
una

BBDD podría ser el siguiente.

Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese necesario) y seguirían
la

misma estructura de columnas, tras implementarlo en una BBDD.

Elementos del modelo entidad-relación
Atributos
 Elementos del modelo entidad-
relación
Relación
Es un vínculo que nos permite def inir una dependencia entre varias entidades, es decir, nos permite
exigir que varias entidades compartan ciertos atributos de forma indispensable.

Por ejemplo, los empleados del taller (de la entidad "Empleados") tienen un cargo (según la entidad
"Cargo del empleado"). Es decir, un atributo de la entidad "Empleados" especificará que cargo tiene en
el taller, y tiene que ser idéntico al que ya existe en la entidad "Cargo del empleado".

Las relaciones se muestran en los diagramas como rombos, que se unen a las entidades mediante
líneas.
Elementos del modelo entidad-relación
Relación

Esto se entiende mejor en una tabla (de una implementación en una BBDD), por lo que se ve en el

ejemplo como se representaría (resaltada la relación, que posteriormente veremos como se haría).
 Elementos del modelo entidad-
relación
Relaciones de cardinalidad
Podemos encontrar distintos tipos de relaciones según como participen en ellas las entidades. Es decir,
en el caso anterior cada empleado puede tener un cargo, pero un mismo cargo lo pueden compartir
varios empleados.

Esto complementa a las representaciones de las relaciones, mediante un intervalo en cada extremo de
la relación que especif ica cuantos objetos o cosas (de cada entidad) pueden intervenir en esa
relación.

Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por ejemplo, si tuviésemos una
entidad con distintos chasis y otra con matrículas deberíamos de determinar que cada chasis solo
puede tener una matrícula (y cada matrícula un chasis, ni más en ningún caso).
Elementos del modelo entidad-relación
Relaciones de cardinalidad

Uno a varios o varios a uno: determina que un registro de una entidad puede estar relacionado con

varios de otra entidad, pero en esta entidad existir solo una vez. Como ha sido en el caso anterior

del trabajador del taller.

Varios a varios: determina que una entidad puede relacionarse con otra con ninguno o varios registros

y viceversa. Por ejemplo, en el taller un coche puede ser reparado por varios mecánicos distintos y esos

mecánicos pueden reparar varios coches distintos.

Los indicadores numéricos indican el primero el número mínimo de registros en una relación
y

posteriormente el máximo (si no hay límite se representa con una "n").

 La Participación de una entidad

• La participación de una entidad también se conoce como cardinalidad de la entidad dentro

de una relación.
• Una misma entidad puede tener distinta cardinalidad dentro de distintas relaciones. Para
obtener la participación, se debe fijar una ocurrencia concreta de una entidad y averiguar
cuántas ocurrencias de la otra entidad le corresponden como mínimo y como máximo.
• Después realizar lo mismo en el otro sentido. Estas ocurrencias mínimas y máximas
(llamadas también participación de una entidad) se representarán entre paréntesis y con
letras minúsculas en el lado de la relación opuesto a la entidad cuyas ocurrencias se fijan.
• Para determinar la cardinalidad nos quedamos con las participaciones máximas de ambas
y se representan con letras mayúsculas separadas por dos puntos junto al símbolo de la
relación.
Un cliente «compra» como mínimo 1 coche y como máximo puede comprar más
de un coche, es decir, varios coches.
Ese varios se representa con la letra «n»→Participación (1,n)) y se pone en el
lado opuesto a CLIENTE, es decir, junto a COCHE.
Un coche «es comprado» como mínimo por 1 cliente y como máximo por 1
cliente→Participación (1,1) y se pone en el lado opuesto a COCHE, es decir,
junto a CLIENTE. Para determinar la cardinalidad nos quedamos con las dos
participaciones máximas y la «n» se pone en mayúsculas «N». Es decir→1:N.
Un empleado «trabaja» como mínimo 1 departamento y como máximo puede trabajar en
varios. Ese varios se representa con la letra «n»→Participación(1,n)) y se pone en el lado
opuesto a EMPLEADO, es decir, junto a DEPARTAMENTO.
Un departamento «tiene» como mínimo por 1 empleado y como máximo puede tener
varios→Participación (1,n) y se pone en el lado opuesto a DEPARTAMENTO, es decir,
junto a EMPLEADO.
Para determinar la cardinalidad nos quedamos con las dos participaciones máximas y la
«n» se pone en mayúsculas «N» y para diferenciar el otro «varios» en lugar de «N»
ponemos «M» (Igual que cuando en matemáticas había dos variables no se ponía x e x
sino x e y). Es decir→N:M.
 Atributos propios de una relación

• Las relaciones también pueden tener atributos, se les denominan atributos propios.
• Son aquellos atributos cuyo valor sólo se puede obtener en la relación, puesto que
dependen de todas las entidades que participan en la relación.

Tenemos la relación «Compra» entre cliente y producto. Así un cliente puede

comprar uno o varios productos, y un producto puede ser comprado por uno o varios
clientes. Encontramos una serie de atributos propios de cada una de
las entidades [CLIENTE (Cod_Cliente, Nombre, Dirección, edad, teléfono) y
PRODUCTO (Cod_Producto, Nombre,Descripción, Precio_Unidad)], pero también
podemos observar como el atributo «Cantidad» es un atributo de la relación.
¿Por qué? Pues porque un mismo cliente puede comprar distintas cantidades de
distintos productos y un mismo producto puede ser comprado en distintas cantidades
por distintos clientes.
Es decir el atributo cantidad depende del cliente y del producto de que se traten.
Elementos del modelo entidad-relación
Claves
• Es el atributo de una entidad, al que le aplicamos una restricción que lo distingue de los demás
registros (no permitiendo que el atributo específico se repita en la entidad) o le aplica un vínculo
(exactamente como comentábamos en las relaciones). Estos son los distintos tipos:

• Clave primaria: identifica inequívocamente un solo atributo no permitiendo que se repita en la

misma entidad. Como sería la matrícula o el número de chasis de un coche (no puede existir
dos veces el mismo).

• Clave externa o clave foránea: este campo tiene que estar estrictamente relacionado con la
clave primaria de otra entidad, para así exigir que exista previamente ese clave. Anteriormente
hemos hablado de ello cuando comentábamos que un empleado indispensablemente tiene que
tener un cargo (que lo hemos representado numéricamente), por lo cual si intentásemos darle un
cargo inexistente el gestor de bases de datos nos devolvería un error.
 Representación del problema
Fase de análisis

Especificación de Requisitos Software o E.R.S. (SRS en inglés)

Los informáticos se reúnen con los futuros usuarios del sistema para recopilar
lainformación que necesitan para saber que desean dichos usuarios.
De la reunión, se extrae se extrae el documento más importante del análisis, el
documento de Especificación de Requisitos Software o E.R.S. A partir de dicha
E.R.S. Se extrae toda la información necesaria para la modelización de datos.
 EJEMPLO COCINAS
•Supongamos que después de unas entrevistas previas, obtenemos que la empresa
lo que desea es lo siguiente: Especificación de requisitos:
•La empresa desea realizar un control de sus ventas y montajes, para lo cual se tiene
en cuenta:
1.De cada modelo de cocina nos interesa el número de referencia del modelo.
2.De un montador nos interesa su NIF, nombre, dirección, teléfono de contacto y el
número de cocinas que ha montado de cada modelo.

3.Cada modelo cocina lo debe montar al menos un montador, y el mismo montador

puede montar varios modelos, porque no se especializan en ninguno en concreto.

4.De un cliente nos interesa su NIF, nombre, dirección y teléfono. Cada modelo de
cocina pueden comprarlo uno o varios clientes, y el mismo cliente puede comprar

varias modelos de cocinas.

 Representación del problema

Fase 1 del Diseño: Diseño Conceptual. Modelo Entidad

/Relación (E/R)
A partir de la E.R.S., se diseñará un modelo que tiene un gran poder expresivo para
poder comunicarse con el usuario que no experto en informática.
Necesario un futuro usuario de la BD que conozca a fondo todas las características
de la misma.
El modelo que utilizaremos en este módulo y que explicaremos en la siguiente
unidad es el modelo Entidad/Relación.
 Representación del problema
Diseño Conceptual del Ejemplo COCINAS

A partir del E.R.S, que supone una descripción del mundo real sobre el que queremos diseñar nuestra base de

datos, el primer paso será diseñar el esquema conceptual que lo describe.

 Representación del problema

Fase 2 del diseño: Diseño Lógico. Modelo Relacional

A partir del modelo Entidad/Relación se creará un modelo que suele ser más difícil de
entender para el usuario final y que generalmente tiene una traducción directa al modelo
físico en que entiende el SGBD.
El modelo lógico elegido dependerá de la BD, pues no es lo mismo modelizar una BD
orientada a objetos que una BD relacional. El modelo que utilizaremos en este módulo
es el modelo relacional.
 Representación del problema
Diseño Lógico

A partir del esquema conceptual, aprenderemos a obtener el esquema lógico, el cual va a depender del SGBD que

utilicemos. En nuestro caso nos basaremos en el modelo relacional que es el más extendido. De nuevo, y a modo

de ejemplos presento como quedaría el esquema relacional del ejemplo anterior.

 Representación del problema

Fase 3 del diseño: Diseño Físico. Modelo Físico

Es el resultado de aplicar el modelo lógico a un SGBD concreto. Generalmente está
expresado en un lenguaje de programación de BBDD tipo SQL. DDL de SQL.
 El lenguaje SQL
(Structured Query Language) o lenguaje (de programación) de consulta estructurada.

El SQL es un lenguaje de dominio específico utilizado en programación, diseñado para

administrar, y recuperar información de sistemas de gestión de bases de datos

relacionales.

Una de sus principales características es el manejo del álgebra y el cálculo relacional

para efectuar consultas con el fin de recuperar, de forma sencilla, información de bases

de datos, así como realizar cambios en ellas.

Está estandarizado por la ISO, es decir, todas las bases de datos que soporten SQL

deben tener la misma sintaxis a la hora de aplicar el lenguaje.

 El lenguaje SQL
Se divide en 4 sublenguajes, el total de todos ellos permite al SGBD cumplir con las

funcionalidades requeridas por la CODD.

·Lenguaje DDL: un lenguaje de definición de datos. Permite crear la estructura de la

base de datos(desde tablas hasta usuarios). Sus clausulas son de tipo DROP (eliminar

objetos) y CREATE (Crear objetos).

·Lenguaje DML: un lenguaje de manipulación de datos. Este lenguaje permite con 4

sentencias sencillas seleccionar determinados datos (SELECT), insertar datos (INSERT),

modificarlos (UPDATE) o incluso borrarlos (DELETE).

 El lenguaje SQL

·Lenguaje DCL: un lenguaje de control de datos. Incluye comandos (GRANT y

REVOKE) que permiten al administrador gestionar el acceso a los datos contenidos en la

base de datos.

·Lenguaje TCL: Lenguaje de control de transacciones.Permite ejecutar varios comandos

de forma simultánea como si fuera un comando atómico o invisible. Si es posible ejecutar

todos los comandos se aplica la transacción COMMIT, y si hay algún error se puede

deshacer con (ROLLBACK).

 Relaciones Reflexivas

TRANSFORMACION DE UNA INTERRELACION REFLEXIVA

Se trata de relaciones en las que solo participa una entidad. Como regla general toda relación

reflexiva se convierte en dos tablas: una para la entidad y otra para la relación.

Se pueden presentar los siguientes casos:

Relación 1:1 No se crea una tabla para la relación. La clave de la entidad se repite, con lo que la

tabla resultante tendrá ese atributo dos veces, una como clave primaria y otra como clave ajena de

ella misma.
 Relaciones Reflexivas

TRANSFORMACION DE UNA INTERRELACION REFLEXIVA

Relación 1:N

En este caso hay que tener en cuenta la cardinalidad del lado muchos:

a.Si no es obligatoria se crea una nueva tabla cuya clave será la de la entidad del lado muchos

(Cod_tema_S) y se propaga la clave a la nueva tabla como clave ajena.

b. Si es siempre obligatoria no se crea una nueva tabla.

 Relaciones Reflexivas

TRANSFORMACION DE UNA INTERRELACION REFLEXIVA

Relación N:M

La tabla que resulta de la relación contendrá dos veces la clave primaria de la entidad del lado

muchos, más los atributos de la relación, si los hay. La clave de esta nueva tabla será la

combinación de las dos.

 Paso del diagrama Entidad-
Relación al modelo relacional.
La transformación se realiza empleando las siguientes reglas:

1. Toda entidad se transforma en una tabla.

2. Todo atributo se transforma en columna dentro de la tabla.

3. El identificador único de la entidad se convierte en clave primaria.

 Paso del diagrama Entidad-
Relación al modelo relacional.
La transformación se realiza empleando las siguientes reglas:

Como las relaciones del modelo E/R no tienen equivalente en el modelo relacional, ya que sólo

existen tablas y operaciones entre ellas, es necesario aplicar lo siguiente:

A. En las relaciones M:N se crea una nueva tabla que tendrá como clave primaria la concatenación

de los atributos clave de las entidades que asocia y con los atributos propios de la relación si los

hay. Esta tabla posee dos claves ajenas, una por cada entidad con la que está relacionada.

B. En las relaciones 1:N la entidad del lado N de la relación añade el conjunto de campos

necesarios para incorporar a sus atributos la totalidad de la clave primaria de la entidad del lado 1,

creando una clave ajena, de modo que se puedan relacionar ambas tablas mediante operadores

relacionales. El nombre de la relación desaparece.

 Paso del diagrama Entidad-
Relación al modelo relacional.
C. Las relaciones 1:1 se transforman en función de las cardinalidades:

- Cuando ambas entidades participan con cardinalidades (1,1 ) propagando cualquiera de los

atributos identificadores y sus atributos asociados creando una única tabla con el conjunto de

los atributos de ambas entidades. La clave primaria sería cualquiera de las dos.

- Cuando ambas tablas tienen cardinalidades (0,1) crear una nueva tabla a partir de la relación

con las dos claves de ambas.

- Propagar la clave de la entidad con cardinalidad (1,1) a la entidad que tenga (0,1).
 Paso del diagrama Entidad-
Relación al modelo relacional.
Ejemplo de aplicación de esas reglas

Además de las reglas de transformación que acabamos de ver y que se aplican con carácter

general, existen otros aspectos a tener en cuenta a la hora de obtener un esquema relacional a

partir de un modelo entidad-relación. Los veremos en los siguientes apartados.

 Relació
TRANSFORMACIÓN DE INTERRELACIÓN M:N n M:N
Regla general: Se transforman en una nueva tabla cuya clave se forma, al menos, con la

concatenación de las claves de las entidades que participan en la relación, que son además claves

ajenas que referencian a las tablas en las que son claves primarias. El nombre asignado a la tabla

es el que tenía la relación.

 Relació
TRANSFORMACION DE LA DIMENSION TEMPORAL n M:N
En algunos casos en que la relación tenga atributos de tipo fecha, será necesario incluir al menos

una fecha como parte del atributo identificador principal para recoger la dimensión temporal del

modelo. En otros casos la fecha puede ser una entidad más o solo un atributo.
 RELACI
ÓN 1:N
TRANSFORMACION DE INTERRELACION 1:N

Como norma general se propaga la clave de la entidad que tiene cardinalidad máxima 1 a la que

tiene cardinalidad máxima N.

 RELACI
TRANSFORMACION DE INTERRELACION 1:N ÓN 1:N
EXCEPCIONES

En los siguientes casos interesa más crear una nueva tabla a partir de la relación como en el caso

de correspondencias M:N:

1. Cuando el número de ocurrencias de la entidad que propaga la clave es muy pequeño y cabe la

posibilidad de que al propagar la clave quedan muchos valores repetidos o nulos.

2. Cuando se prevea que en el futuro se puede convertir en una relación M:N

3.Cuando la relación tenga atributos propios. En algunos casos se pueden migrar estos atributos

junto con la clave pero, en general, se crea una nueva tabla.

 RELACI
ÓN 1:N
TRANSFORMACION DE INTERRELACION 1:N

EXCEPCIONES
 RELACI
ÓN 1:N
TRANSFORMACION DE INTERRELACION 1:N

CARDINALIDADES

1. Cuando la entidad que tiene cardinalidad máxima 1, tiene también 1 de cardinalidad mínima,

tendremos que tener en cuenta al propagar la clave que en la tabla que recibe la clave, como clave

extranjera, no pueda tener valores nulos.

 RELACI
ÓN 1:N
TRANSFORMACION DE INTERRELACION 1:N

CARDINALIDADES

2. Cuando la entidad que tiene cardinalidad máxima n, tiene de cardinalidad mínima 1, tendremos

que controlar por software que, al dar de alta una fila de la otra tabla se introduzca al menos una fila

en esta.