administracion de base de datos 2unidad 2 2015

UNIVERSIDAD DE PAMPLONA ADMINISTRACION DE BASES DE DATOS - GRUPO AR

DOCENTE: ALEXIS OLVANY TORRES CH. PRIMER SEMESTRE 2015

Tabla de Contenido

UNIDAD 2: Modelado de Datos

Descripción Temática

Horizontes

Núcleos Temáticos

Proceso de Información

2.1 DESCRIPCIÓN DEL CICLO DE RECEPCIÓN VENTA / EFECTIVO

2.1.1 De las Entidades a las Tablas

2.1.2 Establecer las Comprobaciones de Validación

2.2 DISEÑO CONCEPTUAL DE BASE DE DATOS

2.2.1 Realidad y Modelos

2.2.2 Modelos Conceptuales de Datos

Proceso de Comprensión y Análisis

Solución de Problemas

Síntesis Creativa y Argumentativa

Autoevaluación, Repaso Significativo y Bibliografía Sugerida

Administración de Base de

Datos



UNIDAD 2: Modelado de Datos

Descripción Temática

Los modelos de datos aportan la base conceptual para diseñar aplicaciones que hacen un uso intensivo de datos, así como la base formal para las herramientas y técnicas empleadas en el desarrollo y uso de sistemas de información. Con respecto al diseño de bases de datos, el modelado de datos puede ser descrito así "dados los requerimientos de información y proceso de una aplicación de uso intensivo de datos (por ejemplo, un sistema de información), construir una representación de la aplicación que capture las propiedades estáticas y dinámicas requeridas para dar soporte a los procesos deseados (por ejemplo, transacciones y consultas).

En la presente unidad se estudiará la temática relacionada con el modelado de datos con el propósito de brindar algunas ideas concernientes a los pasos necesarios para diseñar una base de datos sencilla.

Se partirá con la explicación de conceptos fundamentales, para así, a medida que se avanza en el estudio de la unidad, lograr la comprensión de temas más profundos. Los contenidos a estudiar son: Descripción del Ciclo de Recepción Venta / Efectivo y Diseño Conceptual de Base de Datos; esta temática se apoya en conceptos fundamentales y ejemplos resueltos que se tendrán en cuenta al desarrollar los ejercicios que se proponen en la unidad.



� Comprender qué es un modelo de datos.

� Comprender la importancia de los modelos de datos en el desarrollo y uso de sistemas de información.

� Conocer las herramientas y técnicas utilizadas para el diseño de las bases de datos.

� Identificar las entidades que representen claramente los modelos de datos y las relaciones entre ellas.

� Implementar las entidades de los modelos de datos en forma organizada que representen con precisión su estructura.

� Comprender las reglas gobernantes de interrelación para definir los modelos de datos en SGBD.

� Establecer test de validación en el diseño e implementación de los modelos de datos que evite la incorporación de información incorrecta.

� Comprender un modelo orientado a objetos.

� Descripción del Ciclo de Recepción Venta / Efectivo

� Diseño Conceptual de Base de Datos

La investigación moderna sobre modelos de datos se ha centrado en los aspectos lógicos de las bases de datos y sobre los conceptos, herramientas y técnicas para el diseño de las mismas. Aspectos relativos a la implementación de los modelos, tales como velocidad de ejecución, concurrencia, integridad física y arquitecturas no son factores relevantes en el estadio de análisis de modelos de datos. La investigación más temprana sobre modelos de datos sí estaba más centrada en

Horizontes

Núcleos Temáticos y Problemáticos

Proceso de Información



los aspectos de representación física. Cuando hablamos de modelos de datos clásicos, nos estamos refiriendo a la segunda de las generaciones de modelos de datos, la cual distingue cuatro etapas:

• Modelos de datos primitivos (orientados al fichero).

• Modelos de datos clásicos.

• Modelos de datos semánticos.

• Modelos de datos de propósito específico (orientados a la aplicación).

Los modelos de datos primitivos estaban absolutamente orientados al fichero: las entidades se representan en registros (divididos en campos, que representan sus propiedades), que se agrupan en ficheros. Las relaciones entre entidades son únicamente aquellas que pueden ser representadas usando directorios, por ejemplo índices y listas invertidas. Un ejemplo de DBMS comercial de fichero, concretamente del tipo "lista invertida", es el CA-DATACOMB de Computer Associates International.

Los modelos de datos clásicos son tres: el jerárquico, el de red y el relacional.

2.1 DESCRIPCIÓN DEL CICLO DE RECEPCIÓN VENTA / EFECTIVO

El primer paso para desarrollar una base de datos es crear un modelo de datos conceptual de sus acciones de negocios. Se necesitan las siguientes entidades para ilustrar el ciclo de recepción venta/efectivo: CLIENTE, PROYECTO, EMPLEADO, TIPO _ COMIDA y PAGO. En nuestro modelo de datos se representaran estas entidades con rectángulos. Por ejemplo, la entidad PROYECTO es:



2.2.2 Modelos Conceptuales de Datos

Una metodología de modelado de datos que se estudiará y utilizará, podría llamarse modelo orientado a objetos porque considera la representación en la computadora de las entidades del mundo real como "objetos" que tienen su propia identidad y atributos y que participan en las relaciones, en lugar de la forma tradicional de considerarlas como registros en un sistema orientado a archivos.

Es generalmente, reconocido que las representaciones orientadas a objeto son más precisas para expresar la esencia lógica de las aplicaciones del mundo real que las representaciones basadas en registros. Por esta razón, esta metodología también puede llamarse semántica porque proporciona un medio poderoso para asociar los significados de las cosas en la realidad con las construcciones en el modelo. Desde principios de los setenta han sido propuestos varios modelos conceptuales y semánticos de datos. Se usará una metodología genérica de modelado, la cual tiene aspectos en común con las metodologías propuestas. Por simplicidad, a lo largo del libro se le llamará a este modelo, modelo conceptual de datos.

Modelo Semántico u Orientado a Objetos

Las bases de datos orientadas a objetos son el resultado de la convergencia de dos disciplinas de investigación: el modelado semántico de datos y los lenguajes orientados a objeto.

Estas disciplinas se desarrollaron de manera independiente, pero en los ochenta comenzaron a mezclarse con importantes implicaciones en el procesamiento de bases de datos.

El modelado semántico de datos fue originalmente desarrollado con el propósito de incrementar la efectividad y la precisión del diseño de bases de datos (Hull and King, 1987). Los métodos de modelado semántico fueron considerados



apropiados para muchos problemas de usuario y podrían ser convertidos con facilidad a modelos con realizaciones basadas en registros tales como los modelos jerárquico, de redes y relacional.

El modelo de entidad-relación de Chen (E-R) ha sido el modelo semántico más popular y comúnmente se puede encontrar en libros sobre modelado conceptual de datos y diseño de bases de datos. Mientras que aquellos dedicados al modelado semántico de datos tienen que ver primariamente con las estructuras de los datos, los que desarrollan los lenguajes de programación orientados a objetos están más interesados en el comportamiento de los datos objetos. Esto es, están buscando formas de manipular los datos que se centran en los datos y en las capacidades de manipulación del lenguaje (consulta, compute, actualización). La estructura de los datos pasa a un piano secundario.

Los elementos principales de un modelo conceptual de datos son los objetos y las relaciones. Los objetos se conciben a menudo como nombres, y las relaciones se ven como verbos. Aunque algunos modelos conceptuales de datos proporcionan algunas construcciones adicionales, los objetos y las relaciones son suficientemente poderosos para los problemas que se considerarán.

Objetos

Los objetos representan cosas que son importantes para los usuarios en el segmento de la realidad que queremos modelar. Ejemplos de objetos son las personas, los automóviles, los árboles, las maquinas lavaplatos, las casas, los martillos, los libros. Estos son objetos concretos. Objetos conceptuales son compañías, oficios, organizaciones, diseños de productos, transacciones de negocios y clasificaciones de los trabajos.



ADMINISTRACION DE BASES DE DATOS

SISTEMA DE GESTIÓN DE BASES DE DATOS (SGBD)

Una base de datos es una colección de información ordenada e interrelacionada que es

de importancia para una empresa.

La creación de una base de datos debe ser realizada cuidadosamente procurando cumplir

con dos objetivos (entre otros):

*Permitir un fácil acceso a la información: El sistema debe ser facilitador de alto

rendimiento, la velocidad es un factor esencial así como la consistencia de los datos.

*Evitar redundancia de la información: La información almacenada ocupará

irremediablemente un espacio en memoria por lo cual es de vital importancia eliminar la

posibilidad de almacenar datos repetidos ya que adicionalmente podrían llevarnos a

inconsistencias en la información .

Un sistema de gestión de bases de datos (SGBD) consiste en una colección de datos

interrelacionados y un conjunto de programas para acceder a dichos datos. El primer

objetivo de un SGBD es proporcionar un entorno que sea tanto práctico como eficiente de

usar en la recuperación y el almacenamiento de información de la base de datos.

Los SBD se diseñan para gestionar grandes cantidades de información. La gestión de los

datos implica tanto la definición de estructuras para almacenar la información como la

provisión de mecanismos para la manipulación de la misma. Los SBD deben proporcionar

la fiabilidad de la información almacenada, a pesar de las caídas del sistema o del intento

de acceso sin autorización.



Anteriormente se utilizaba el sistema de procesamiento de archivos en el cual toda la

información de la empresa se almacenaba en archivos permanentes manejados por un

sistema operativo convencional, se tenían que escribir diversos programas de aplicación

para extraer registros y añadir registros a los archivos adecuados.

Los principales inconvenientes de la organización en un sistema de procesamiento de

archivos son:

* Redundancia e inconsistencia de datos. Como los programas y archivos son creados

por diferentes personas a través del tiempo, estos pueden tener diferentes formatos y

escritos en diferentes lenguajes de programación, la información puede estar duplicada en

los diversos lugares. Esto conduce a un almacenamiento y coste de acceso más altos y

puede conducir a inconsistencia de datos.

* Dificultad en el acceso de datos. Algunas peticiones no previstas en el sistema

original, no hay un programa de aplicación a la mano para hacerlo. Sin embargo hay

programas para mostrar la lista de total y las opciones aquí son; primero, de esa lista

sacar la información manualmente y segundo, mandar a un programador a hacer un

programa que haga esa consulta. Y por cada consulta se debería hacer lo mismo.

* Aislamiento de datos. La creación de nuevos programas de aplicación es muy difícil ya

que los archivos pueden estar en diversos formatos y se tiene que recopilar la información

dispersa en cada uno de los archivos.

* Problemas de integridad. Los valores de los datos almacenados en la base de datos

deben satisfacer ciertos tipos de ligaduras de consistencia. Los desarrolladores hacen

cumplir esas ligaduras en el sistema añadiendo el código apropiado en los diversos

programas de aplicación.

* Problemas de atomicidad. Es necesario asegurar que en caso de fallo se regrese a un

estado en el cual había un estado de consistencia. Y en estos casos pueden haber

inconsistencias si se trabaja con archivos, y lo que debe de ocurrir es que si hay cambios

se hagan completamente o no se haga nada en absoluto. Así se pueden evitar estas

inconsistencias que no son seguras en uno que maneje archivos.



* Problemas de seguridad. No todos los usuarios de un sistema de bases de datos

deberían poder acceder a todos los datos. Como los programas de aplicación se añaden

de una forma ad hoc, es difícil garantizar esta seguridad.

Estructura del sistema completo (Figura 1)

Los componentes funcionales de un sistema de bases de datos se pueden dividir a

grandes rasgos en componentes de procesamiento de consultas y componentes de

gestión de almacenamiento.

Los componentes de procesamiento de consultas incluyen:

* Compilador del LMD, que traduce las instrucciones del LMD en lenguaje de consultas a

instrucciones a bajo nivel que entiende el motor de evaluación de consultas.

* Precompilador del LMD incorporado, que convierte las instrucciones del LMD

incorporadas en un programa de aplicación en llamadas a procedimientos normales en el

lenguaje anfitrión.

* Intérprete del LDD, que interpreta las instrucciones del LDD y las registra en un conjunto

de tablas que contienen metadatos.

* Motor de evaluación de consultas que ejecuta las instrucciones a bajo nivel generadas

por el compilador del LMD.

Los componentes de gestión de almacenamiento proporcionan la interfaz entre los datos

de bajo nivel almacenados en la base de datos y los programas de aplicación y envío de

consultas al sistema. El gestor de almacenamiento tiene:

* Gestor de autorización e integridad que comprueba que se satisfagan las ligaduras de

integridad y la autorización de los usuarios para acceder a los datos.



* Gestor de transacciones que asegura que la base de datos quede en un estado

consistente a pesar de los fallos del sistema y que las ejecuciones de transacciones

concurrentes ocurran sin conflictos.

* Gestor de archivos que gestiona la reserva de espacio de almacenamiento de disco y

las estructuras de datos usadas para representar la información almacenada en el disco.

* Gestor de memoria intermedia que es responsable de traer los datos del disco de

almacenamiento a memoria principal y dec idir que datos traer a memoria caché.

También se necesitan diversas estructuras de datos como parte de la implementación

física del sistema:

* Archivos de datos que almacenan la base de datos en sí.

* Diccionario de datos que almacena metadatos acerca de la estructura de la base de

datos.

* Indices que proporcionan acceso rápido a elementos de datos que tienen valores

particulares.

* Datos estáticos que almacenan información estadística sobre los datos en la base de

datos, el procesador de consultas usa esta información para seleccionar las formas

eficientes para ejecutar una consulta.

Roles en el SGBD

Administrador base de datos

Administración de datos

� Planificación de la base de datos

� Desarrollo de estándares (ej.: nombres), políticas y procedimientos

� Diseño lógico de la base de datos



Administración de bases de datos

� Diseño e implementación de la base de datos

� Acceso y control (usuarios y passwords)

� Mantenimiento (ej.: mantenimiento para mejor performance)

� Respaldo

Diseñador de base de datos

Diseño lógico de la base de datos

� ¿Qué datos deben ser almacenados?

� Definir vista parcial

� ¿Cómo deben organizarse los datos?

� ¿Cuáles son los usos típicos de los datos?

Programador de aplicaciones

� Programas que usen las bases de datos

� Interfaces a otros sistemas

Usuarios finales

Paramétricos o simples

� Usuarios de las aplicaciones finales

� Consultas pre-fijadas

Expertos

� Reportes y análisis



Figura 1. Estructura del Sistema Completo



Abstracción de datos

El propósito principal de un sistema de bases de datos es proporcionar a los usuarios una

visión abstracta de los datos. Es decir, el sistema esconde ciertos detalles de cómo se

almacenan y mantienen los datos.

Para que el sistema sea útil, debe recuperar los datos eficientemente. Esto ha conducido

al diseño de estructuras complejas para la representación de los datos en la base de

datos. Los desarrolladores esconden la complejidad a través de los niveles de abstracción

para simplificar la interacción de los usuarios con el sistema:

Nivel físico. El nivel más bajo de abstracción, describe como se almacenan

realmente los datos. En el nivel físico se describen en detalle las estructuras de

datos complejas de bajo nivel.

Nivel lógico. El siguiente nivel de abstracción describe que datos se almacenan en

la base de datos y que relaciones existen entre esos datos.

Nivel de vistas. Este nivel solo describe parte de la base de datos completa. A

muchos usuarios no les importará el nivel lógico, solo querrán ver parte de la

información. Para la simplificación de la interacción del usuario se crea un nivel

de vistas.

La colección de información almacenada en la base de datos en un momento

particular se llama ejemplar (instancia) de la base de datos. El diseño completo se llama

esquema de la base de datos.



Un esquema de bases de datos se expresa mediante un conjunto de definiciones que se

expresa en un lenguaje de definición de datos (LDD). Las instrucciones del LDD se

compilan dando lugar a un conjunto de tablas que se almacenan en un archivo especial,

el diccionario de datos contiene metadatos que son datos acerca de los datos.

Un lenguaje de manipulación de datos (LMD) es un lenguaje que permite a los usuarios

acceder o manipular datos. Hay dos tipos: LMD procedimentales que requieren que se

especifiquen los datos requeridos y como se buscarán, y los LMD no procedimentales que

solo requiere que se especifique que datos se requieren.

Independencia de datos

La capacidad para modificar una definición de esquema en un nivel sin que afecte a una

definición de esquema en el siguiente nivel más alto se llama independencia de datos.

Hay dos niveles de independencia.

Independencia física de datos. Es la capacidad para modificar el esquema físico

sin provocar que los programas de aplicación tengan que rescribirse.

Independencia lógica de datos. Es la capacidad para modificar el esquema

lógico

sin causar que los programas de aplicación tengan que rescribirse. Las modificaciones

en el nivel lógico son necesarias siempre que la estructura lógica de la base de datos

se altere.



Modelos de datos

La parte esencial de la estructura de base de datos es el modelo de datos: una colección

de herramientas conceptuales para describir los datos, las relaciones de datos, la

semántica de los datos y las ligaduras de consistencia. Los diferentes modelos de datos

que se han propuesto se clasifican en tres grupos diferentes: modelos lógicos basados en

objetos, modelos lógicos basados en registros y modelos físicos .

Los modelos lógicos basados en objetos se usan para describir datos en los niveles lógico

y de vistas. Proporcionan capacidades estructurales muy flexibles y permiten que las

ligaduras se especifiquen explícitamente. Los más conocidos son:

Modelo entidad – relación.

Modelo orientado a objetos.

Modelo de datos semánticos.

Modelo de datos funcional.

Modelo entidad – relación

Esta basado en una percepción del mundo real que consta de una colección de objetos

básicos, llamados entidades, y de las relaciones entre estos objetos. Una entidad es una

cosa u objeto que es distinguible de otros objetos. Una relación es una asociación entre

varias entidades. Se maneja la correspondencia de cardinalidades que expresa el número

de entidades que pueden estar relacionadas con una entidad por medio de relaciones.

Modelo orientado a objetos

Está basado en una colección de objetos. Un objeto contiene valores almacenados en

variables ejemplares dentro de este objeto. Contiene fragmentos de código que operan



dentro del mismo y a éstos se les llama métodos. La única manera en que pueden

acceder a la base de datos es a través del paso de mensajes a otro objeto.

Los Modelos lógicos basados en registros se usan para especificar la estructura lógica

completa de la base de datos para proporcionar una descripción de alto nivel de la

implementación. Este se estructura en registros de formato fijo de diferentes tipos. En

cada tipo de registro se define un número de campos y cada uno tiene una longitud fija.

Los principales modelos trabajados a través del tiempo son el modelo relacional, el de red

y el jerárquico.

Modelo relacional

Se usa una colección de tablas para representar tanto los datos como las relaciones entre

ellos. Cada tabla contiene varias columnas, y cada columna tienen un nombre único.

Modelo de red (CODASYL-DBTG)

Se representan por medio de colecciones de registros y las relaciones entre los datos se

representan por medio de enlaces que se pueden ver como apuntadores. Los registros se

organizan como colecciones de grafos dirigidos.

Modelo jerárquico (IMS/DL1 de IBM)

Es similar al modelo de redes, en el sentido en que los datos y relaciones entre los datos

se representan mediante registros y enlaces. La diferencia es que en lugar de organizarse

como grafos estos lo hacen como colecciones de árboles.

El Modelo de datos físico se usa para describir datos en un nivel más bajo. Los más

conocidos son el modelo de unificación y el modelo de memoria por marcos.


DOCENTE: ESP. ALEXIS OLVANY TORRES CH. PRIMER SEMESTRE 2013

Figura 2. Esquemas y Niveles.



Figura 3. Flujo de Datos y Control.

Figura 4. Modelos de Bases de Datos.



Reglas de integridad

Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las

reglas de integridad que los datos almacenados en dicha estructura deben cumplir para

garantizar que son correctos.

Al definir cada atributo sobre un dominio se impone una restricción sobre el conjunto de

valores permitidos para cada atributo. A este tipo de restricciones se les denomina

restricciones de dominios. Hay además dos reglas de integridad muy importantes que

son restricciones que se deben cumplir en todas las bases de datos relacionales y en

todos sus estados o instancias (las reglas se deben cumplir todo el tiempo). Estas

reglas son la regla de integridad de entidades y la regla de integridad referencial. Antes

de definirlas, es preciso conocer el concepto de nulo.

Nulos

Cuando en una tupla un atributo es desconocido, se dice que es nulo. Un nulo no

representa el valor cero ni la cadena vacía, éstos son valores que tienen significado. El

nulo implica ausencia de información, bien porque al insertar la tupla se desconocía el

valor del atributo, o bien porque para dicha tupla el atributo no tiene sentido.

Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa

problemas de implementación. De hecho, no todos los SGBD relacionales soportan los

nulos.

Regla de integridad de entidades

La primera regla de integridad se aplica a las claves primarias de las relaciones base:

ninguno de los atributos que componen la clave primaria puede ser nulo.

Por definición, una clave primaria es un identificador irreducible que se utiliza para

identificar de modo único las tuplas. Que es irreducible significa que ningún

subconjunto de la clave primaria sirve para identificar las tuplas de modo único. Si se



permite que parte de la clave primaria sea nula, se está diciendo que no todos sus

atributos son necesarios para distinguir las tuplas, con lo que se contradice la

irreducibilidad.

Nótese que esta regla sólo se aplica a las relaciones base y a las claves primarias, no a

las claves alternativas.

Regla de integridad referencial

La segunda regla de integridad se aplica a las claves ajenas: si en una relación hay

alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la

que hace referencia, o bien, deben ser completamente nulos.

La regla de integridad referencial se enmarca en términos de estados de la base de

datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión

es ¿qué hacer si estando en un estado legal, llega una petición para realizar una

operación que conduce a un estado ilegal? Existen dos opciones: rechazar la

operación, o bien aceptar la operación y realizar operaciones adicionales

compensatorias que conduzcan a un estado legal.

Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres

preguntas:

• Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos?

• Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave

ajena?

o Restringir: no se permite borrar la tupla referenciada.

o Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que

la referencian mediante la clave ajena.

o Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a

nulo la clave ajena (sólo si acepta nulos).

• Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria

de la tupla referenciada por la clave ajena?



o Restringir: no se permite modificar el valor de la clave primaria de la tupla

referenciada.

o Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se

propaga la modificación a las tuplas que la referencian mediante la clave ajena.

o Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen

a nulo la clave ajena (sólo si acepta nulos).

Modelado Entidad-Relación

Un diagrama o modelo entidad-relación (a veces denominado por su siglas, E-R

"Entity relationship", o, "DER" Diagrama de Entidad Relación) es una herramienta para

el modelado de datos de un sistema de información. Estos modelos expresan

entidades relevantes para un sistema de información así como sus interrelaciones y

propiedades.

El Modelo Entidad-Relación.

1. Se elabora el diagrama (o diagramas) entidad-relación.

2. Se completa el modelo con listas de atributos y una descripción de otras

restricciones que no se pueden reflejar en el diagrama.

Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia

para lograr buenos modelos de datos.

El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras

técnicas para lograr un modelo directamente implementable en una base de datos.

Brevemente:

• Transformación de relaciones múltiples en binarias.

• Normalización de una base de datos de relaciones (algunas relaciones pueden

transformarse en atributos y viceversa).

• Conversión en tablas (en caso de utilizar una base de datos relacional).



Base Teórica y Conceptual

El modelo de datos entidad-relación está basado en una percepción del mundo real

que consta de una colección de objetos básicos, llamados entidades, y de relaciones

entre esos objetos.

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.

Algunos 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 propiedades que describen a cada entidad en un conjunto de

entidades.



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, 18 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.

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.

Relación

Describe cierta dependencia entre entidades o permite la asociación de las mismas.

Ejemplo: Dadas dos entidades "Habitación 502" y "Mark", es posible relacionar que la



habitación 502 se encuentra ocupada por el huésped de nombre Mark.

Una relación tiene sentido al expresar las entidades que relaciona. En el ejemplo

anterior, Un Huésped (entidad), se aloja (relación) en una habitación (entidad).

Conjunto de relaciones

Consiste en una colección, o conjunto, de relaciones de la misma naturaleza.

Ejemplo:

Dados los conjuntos de entidades "Habitación" y "Huésped", todas las relaciones de

la forma habitación-huésped, permiten obtener la información de los huéspedes y sus

respectivas habitaciones.

La dependencia o asociación entre los conjuntos de entidades es llamada

participación. En el ejemplo anterior los conjuntos de entidades "Habitación" y

"Huésped" participan en el conjunto de relaciones habitación-huésped.

Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades

participantes en la relación.

Restricciones

Son reglas que deben mantener los datos almacenados en la base de datos. No se

deben quebrantar a menos que tenga otra relación de una tabla de uno a muchos.

Correspondencia de cardinalidades

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.

• 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.

• 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.

• Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas

entidades en B y viceversa.

Restricciones de participación

Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A,

dicha participación puede ser de dos tipos:

• Total: Cuando cada entidad en A participa en al menos una relación de R.

• Parcial: Cuando al menos una entidad en A NO participa en alguna relación de

R.

Claves

Es un subconjunto del conjunto de atributos comunes en una colección de entidades,

que permite identificar unívocamente cada una de las entidades pertenecientes a dicha

colección. Asimismo, permiten distinguir entre sí las relaciones de un conjunto de

relaciones.

Dentro de los conjuntos de entidades existen los siguientes tipos de claves:



• Superclave: Es un subconjunto de atributos que permite distinguir

unívocamente cada una de las entidades de un conjunto de entidades. Si se

añade un atributo al anterior subconjunto, el resultado seguirá siendo una

superclave.

• Clave candidata: Dada una superclave, si ésta deja de serlo quitando

únicamente uno de los atributos que la componen, entonces ésta es una clave

candidata.

• Clave primaria: Es una clave candidata, elegida por el diseñador de la base

de datos, para identificar unívocamente las entidades en un conjunto de

entidades.

Los valores de los atributos de una clave, no pueden ser todos iguales para dos o más

instancias.

Para poder distinguir unívocamente las relaciones en un conjunto de relaciones R, se

deben considerar dos casos:

• R NO tiene atributos asociados: En este caso, se usa como clave

primaria de R la unión de las claves primarias de todos los conjuntos de

entidades participantes.

• R tiene atributos asociados: En este caso, se usa como clave primaria

de R la unión de los atributos asociados y las claves primarias de todos los

conjuntos de entidades participantes.

Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria

está compuesto de relaciones binarias, con los conjuntos de entidades participantes A

y B, se consideran los siguientes casos, según sus cardinalidades:



• R es de muchos a uno de A a B entonces sólo se toma la clave primaria de A,

como clave primaria de R.

• R es de uno a muchos de A a B entonces se toma sólo la clave primaria de B,

como clave primaria de R.

• R es de uno a uno de A a B entonces se toma cualquiera de las dos claves

primarias, como clave primaria de R.

• R es de muchos a muchos de A a B entonces se toma la unión de los atributos

que conforman las claves primarias de A y de B, como clave primaria de R.

Diagrama entidad-relación

Anteriormente detallamos los conceptos relacionados al modelo ER, en esta sección

profundizaremos en como representarlos gráficamente. Cabe destacar que para todo

proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan

conocimiento necesario y además fundamentan nuestro modelo al momento de

presentarlo a terceros.

Formalmente, los diagramas ER son un lenguaje gráfico para describir conceptos.

Informalmente, son simples dibujos o gráficos que describen información que trata un

sistema de información y el software que lo automatiza.

Entidad

Las entidades son el fundamento del modelo entidad relación. Podemos adoptar

como definición de entidad cualquier cosa o parte del mundo que es distinguible del

resto. Por ejemplo, en un sistema bancario, las personas y las cuentas bancarias se

podrían interpretar como entidades. Las entidades pueden representar entes concretos,

como una persona o un avión, o abstractas, como por ejemplo un préstamo o una

reserva. Se representan por medio de un rectángulo.



Atributo

Se representan mediante un círculo o elipse etiquetado mediante un nombre en su

interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha

etiqueta.

Relaciones

Se representa mediante un rombo etiquetado en su interior con un verbo. Este rombo

se debe unir mediante líneas con las entidades (rectángulos) que relaciona.

Por motivos de legibilidad, los atributos no suelen representarse en un diagrama

entidad-relación, sino que se describen textualmente en otros documentos adjuntos.

DIAGRAMAS EXTENDIDOS

DER extendido

Los diagramas Entidad-Relación no cumplen su propósito con eficacia debido a que

tienen limitaciones semánticas. Por ese motivo se suelen utilizar los diagramas

Entidad-Relación extendidos que incorporan algunos elementos más al lenguaje:



Entidades fuertes y débiles

Cuando una entidad participa en una relación puede adquirir un papel fuerte o débil.

Una entidad débil es aquella que no puede existir sin participar en la relación, es decir,

aquella que no puede ser unívocamente identificada solamente por sus atributos. Una

entidad fuerte (también conocida como entidad regular) es aquella que sí puede ser

identificada unívocamente. En los casos en que se requiera, se puede dar que una

entidad fuerte "preste" algunos de sus atributos a una entidad débil para que, esta

última, se pueda identificar.

Las entidades débiles se representan- mediante un doble rectángulo, es decir, un

rectángulo con doble línea.

Cardinalidad de las relaciones

El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación,

respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende del lenguaje

utilizado, la que más se usa actualmente es el unificado. Otra forma de expresar la

cardinalidad es situando un símbolo cerca de la línea que conecta una entidad con una

relación:

• "0" si cada instancia de la entidad no está obligada a participar en la relación.

• "1" si toda instancia de la entidad está obligada a participar en la relación y,

además, solamente participa una vez.

• "N" , "M", ó "*" si cada instancia de la entidad no está obligada a participar en

la relación y puede hacerlo cualquier número de veces.

Ejemplos de relaciones que expresan cardinalidad:

• Cada esposo (entidad) está casado (relación) con una única esposa (entidad) y

viceversa. Es una relación 1:1.



• Una factura (entidad) se emite (relación) a una persona (entidad) y sólo una,

pero una persona puede tener varias facturas emitidas a su nombre. Todas las

facturas se emiten a nombre de alguien. Es una relación 1:N.

• Un cliente (entidad) puede comprar (relación) varios artículos (entidad) y un

artículo puede ser comprado por varios clientes distintos. Es una relación N:M.

Atributos en relaciones

Las relaciones también pueden tener atributos asociados. Se representan igual que los

atributos de las entidades. Un ejemplo típico son las relaciones de tipo "histórico"

donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario

hacer constar la fecha de emisión de una factura a un cliente, y que es posible emitir

duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisión"

de la factura debería colocarse en la relación "se emite".

Herencia

La herencia es un intento de adaptación de estos diagramas al paradigma orientado a

objetos. La herencia es un tipo de relación entre una entidad "padre" y una entidad

"hijo". La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre".

Por tanto, no necesitan ser representadas dos veces en el diagrama. La relación de

herencia se representa mediante un triángulo interconectado por líneas a las entidades.

La entidad conectada por el vértice superior del triángulo es la entidad "padre".

Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se

conectan por la base del triángulo.

Agregación



Ejemplo agregación

Es una abstracción a través de la cual las relaciones se tratan como entidades de un

nivel más alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y

relaciones. Se representa englobando la relación abstraída y las entidades que

participan en ella en un rectángulo. En la figura se muestra un ejemplo de agregación

en el que se representa la situación en la que un profesor, cuando está impartiendo una

clase, puede poner una incidencia ocurrida a lo largo de ésta (se fue la luz, falta la

configuración de un determinado software, etc.).



� Describir con sus propias palabras las diferencias entre una tabla y un campo.

� ¿Cómo se representa una tabla en el diagrama de un sistema de información?

� Con sus palabras definir qué es un Sistema de Información

� ¿Qué es un campo clave y qué objetivo persigue?

Del modelo de datos que se presenta a continuación:

• Crear las tablas

Proceso de Comprensión y Análisis

Solución de Problemas



• Aplicar las reglas de tablas que gobiernan las interrelaciones

• Mostrar el modelo de datos modificado

• Establecer las comprobaciones de validación que considere.

C. J, Date. Introducción a los Sistemas de Bases de Datos. Volumen I. séptima Edición. E.U.A. Adisson – Wesley Iberoamericana.

GARY W, Hansen. Y JAMES V. Hansen. Diseño y Administración de Bases de Datos. Quinta Edición. España. Prentice Hall Inc.

Bibliografía Sugerida

administracion de base de datos 2unidad 2 2015

Documents