Base de Datos

Conceptos

Entidad: es una “cosa” u “objeto” en el mundo real que es distinguible de todos los demás objetos, de la cual se guarda información.

Tipo de entidades:

• Fuertes: tienen existencia por si misma. • Débiles: su existencia depende de otra entidad.

Atributos:

• Cada una de las propiedades o características que tiene una entidad. • Los atributos simples se representan mediante un ovalo con el nombre del atributo

dentro.

Tipos de Atributos:

• Atributos candidatos: son atributos que identifican de manera univoca cada ocurrencia de una entidad. Toda entidad debe tener al menos un atributo identificador.

• Atributo identificador primario: una entidad puede tener mas de un atributo (candidato) como identificador, en ese caso, elegimos un atributo como identificador primario, quedando el resto como identificadores alternativos.

• Atributos alternativos: clave candidata no elegida como principal.

• Los atributos compuestos se pueden representar de dos formas:

Monovaluados: son atributos que representan un solo valor para una determinada ocurrencia de una entidad en un momento determinado. Pueden ser simples o compuestas.

Multivaluados: son atributos que pueden representar varios valores simultáneamente para una misma ocurrencia de una entidad. Se representan mediante un doble ovalo.

Relaciones:

– Asociación o correspondencia existente entre entidades. – Se representa mediante un rombo. – Tiene un nombre distintivo.

Sus cardinalidades: Según el problema que se presente serán:

– De uno a uno; interrelación (1:1)– De uno a muchos; interrelación (1:N)– De muchos a muchos; interrelación (N:M)

•El grado de las relaciones. Número de entidades que participan en una interrelación.

•Relación Reflexiva.Relación de un tipo de entidad consigo misma.

•Relación ternaria (grado 3).Relación que une mas de una entidad en este caso tres entidades.

Tipos de relaciones:

• Interrelación Fuerte: Relacionan dos entidades fuertes.

• Interrelación Débil: Relacionan una entidad débil con otra fuerte.

o Dependencia en existencia: Las ocurrencias en un tipo de entidad débil no pueden existir si desaparece la ocurrencia de la entidad fuerte de la que dependen.

o Dependencia en identificación: Además de la condición anterior, las ocurrencias del tipo de entidad débil no se pueden identificar únicamente mediante los atributos propios de la misma y exigen añadir la clave del tipo de entidad fuerte de la cual dependen.

RestriccionesRestricciones inherentes al modelo Entidad/Relación:• Una entidad no puede tener mas de un identificador primario que identifique unívocamente a la entidad.• El orden de los atributos no es significativo (es indiferente).• Cada atributo sólo puede tomar un único valor del dominio, no admitiéndose por lo tanto los grupos repetitivos.• Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo, es decir, un valor desconocido o inexistente.

Restricciones de usuario:• Operación restringida (RESTRICT): solo se permitirá el borrado o modificación de filas de la relación que contiene la clave primaria referenciada si no existen filas con dicha clave en la relación que contiene la clave ajena. En nuestro ejemplo, para borrar un curso de nuestra base de datos, no podría haber ningún alumno matriculado en ese curso, en caso contrario el sistema impediría el borrado.

• Operación con transmisión en cascada (CASCADE): el borrado o modificación de filas en la relación con la clave primaria referenciada implica el borrado o modificación en cascada de las filas de la relación que contiene la clave ajena. En nuestro ejemplo: si se modifica un código de curso (atributo codcur) en la relación CURSO, se debería modificar también dicho atributo en la relación ALUMNO.

• Operación con puesta a nulos (SET NULL) o a valor por defecto (SET DEFAULT): el borrado o modificación de tuplas de la relación con clave primaria implica poner a nulos o poner al valor por defecto los valores de la clave ajena en la otra relación. En nuestro ejemplo: si se borra un curso, a los alumnos matriculados en dicho curso se les deber ía poner el atributo codcurso a nulos, o al valor por defecto declarado al crear la tabla.

Diagrama Entidad-RelaciónConcepto del modelo Entidad/Relación:

Es un modelo conceptual de datos orientado a entidades. Se basa en una técnica de representación gráfica que incorpora información relativa a los datos y las relaciones existentes entre ellos, para darnos una visión del mundo real, eliminando los detalles irrelevantes.

Representación del diagrama Entidad/Relacción:Entidades: se representan mediante un rectángulo.

Atributos: se representan mediante un óvalo.

Fuertes Débiles

Id. Primario Id. Alternativo

Atributo Compuesto Monovaluado:

Atributo Compuesto Multivaluado:

Atributos Compuestos:

Relación:

Ejemplo de Cardinalidades:

Relación Reflexiva:

Relación Ternaria (Grado 3)

Ejemplo de dependencia en existencia

Ejemplo de dependencia en identificación:

Especificación Total:

Solapada:

Participación de una entidad en una relación

Interrelaciones N: M

Cuando la interrelación es de muchos a muchos, se crea otra tabla a partir de la relación donde los identificadores o claves primarias de las entidades pasan a colocarse en la relación.

 

 

 

Ejemplo: Nombre (identificador1, identificador2, Atributo1, Atributo2) 

Interrelaciones 1: N

La clave primaria de la entidad que tenga cardinalidad uno pasa como clave foránea a la entidad 2 que tiene cardinalidad N. La clave foránea se representa mediante un asterisco al lado del nombre.

 

Ejemplo:Entidad2 (Identificador2, Atributo3).Entidad1 (Identificador1, Atribudo1, Identificador2*, Atributo2).

 

Interrelaciones 1:1

Cuando la interrelación es de uno a uno, se crea otra tabla a partir de la relación donde los identificadores o claves primarias de las entidades pasan a colocarse en la relación. 

 

Ejemplo:Hombre (id hombre,… atributos hombres…) Mujer (id mujer…atributos mujer…) Matrimonio (id hombre, id mujer,… atributos interrelacionales…).

 

Interrelaciones 1:1 (1:1)-(0:1)  

La entidad que acoge la clave primaria de la otra entidad como clave foránea, es la que lleva cardinalidad (0:1) en la relación.

 

Ejemplo:Empleado (id empleado,… atributo empleado…) Departamentos (id departamentos, id empleado*… atributos departamentos…+atributos interrelación).

Interrelaciones 1:1 (1:1)-(1:1) 

Cuando en las dos entidades las cardinalidades es (1:1) se puede propagar en clave de cualquiera de ellas a la tabla resultante de la otra.

 

Ejemplo:Entidad 1 (id 1, id 2*, atributos propios y de la relación) Entidad 2 (id 2, atributos propios)

 

Interrelaciones reflexivas (1: N) 

Aquí se hace referencia al identificador de la entidad dos veces uno como clave primaria y otro como clave foránea.

 

  

Ejemplo:Entidad (id entidad, atributo 1, id en rol1)

Interrelaciones reflexivas (N:N)   Aquí se hace una tabla nueva a partir de la relación y esta acoge como clave foránea la clave

primaria de la entidad.

Ejemplo:Entidad (id entidad, atributo 1) Relación (id rol1, id rol2, atributos relación) 

 

Parciales: se hace una tabla para la superclase y las subclases.  

Ejemplo:Alumno (DNI, (nombre), curso…) Profesor (DNI*, nombre, especialidad) Persona (DNI, nombre, curso, especialidad)

Totales: se hace tablas solo para las subclases.

Ejemplo:Alumno (DNI, (nombre), curso…) Profesor (DNI*, nombre, especialidad) Queda igual pero puede representarse la tabla sin persona ya que solo puede haber dos entidades (alumnos

y profesores).

Diagramas Entidad/Relación extendidos

Hay varias aportaciones de diversos autores al modelo Entidad-Relación «básico».

Permiten representar:

Relaciones exclusivas entre sí

Jerarquías de Especialización/Generalización

Agregación de entidades Dos (o más) tipos de relación son exclusivos, respecto de un tipo de entidad que participa en

ambos, si cada instancia del tipo de entidad sólo puede participar en uno de los tipos de relación

La jerarquía o relación que se establece entre uno y otros corresponde a la noción de “es_un” o de “es_un_tipo_de”.

Estas jerarquías pueden formarse por especialización o bien por generalización.

ConclusionesVentajas:

Si se hace un buen diseño de las bases de datos será:

• Muy conciso.• Fácil de comprender.• Fácil de mantener.• Dará eficiencia y fiabilidad a una BD.• Los conceptos podrán ser entendidos por los usuarios finales de las BD.• Podrán ser implementados con facilidad por un SGBD porque no están muy alejados del modo

en que los datos se almacenan. Desventajas:

Los peligros más importantes a evitar: • Redundancia: Información repetida.• Incompletitud: Aspectos mal modelados.• Ambigüedad, por lo que no se puede permitir más de una interpretación para una sola

palabra porque ofrece problemas de comprensión al receptor.• Anomalías en operaciones de modificación de datos.

Práctica:

Fuentes• http://www.oei.eui.upm.es/

• Wikipedia

• Manuel Rodríguez Pozuelo

• Raquel Esquinas Chaparro

• Rafael García Maliga

• Javier Carrión García

• Pablo Alejandro Sánchez Marín

Autores