BASE DE DATOS - abdup.files.wordpress.com · diseñar una base de datos sencilla. ... comenzaron a...

ADMINISTRACION DE DOCENTE:

The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again.

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

Administración de Base de

UNIVERSIDAD DE PAMPLONA ADMINISTRACION DE BASES DE DATOS

DOCENTE: MsC(c)ESP. ALEXIS OLVANY TORRES CH. SEGUNDO SEMESTRE 2017

Tabla de Contenido


Información


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




Síntesis Creativa y Argumentativa


Datos






Autoevaluación, Repaso Significativo y Bibliografía Sugerida


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

Horizontes

Núcleos Temáticos y Problemáticos

Proceso de Información




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


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:





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.

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

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

Está 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.




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?

Restringir: no se permite borrar la tupla referenciada.

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

la referencian mediante la clave ajena.

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?

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

referenciada.

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.

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.

Modelo 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

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

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

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 enti

última, se pueda identificar.



DIAGRAMAS EXTENDIDOS

Relación no cumplen su propósito con eficacia debido a que

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

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


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



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

Relación no cumplen su propósito con eficacia debido a que

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

que incorporan algunos elementos más al lenguaje:

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


solamente por sus atributos. Una



dad débil para que, esta




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



Atributos en relaciones


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



icados 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 es un tipo de relación entre una entidad "padre" y una entidad



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



r la base del triángulo.


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



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


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



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






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

• 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

BASE DE DATOS - abdup.files.wordpress.com · diseñar una base de datos sencilla. ... comenzaron a...

Documents

Transcript of BASE DE DATOS - abdup.files.wordpress.com · diseñar una base de datos sencilla. ... comenzaron a...