Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Encuentra los documentos específicos para los exámenes de tu universidad
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Este documento ofrece una introducción a los modelos lógicos de datos y a los distintos tipos de bases de datos, desde el modelo jerárquico hasta el objeto relacional. El texto explica las diferencias entre estos modelos, sus características y ventajas, y el proceso de transformación del esquema ER al modelo relacional. Además, se mencionan los problemas del esquema relacional y se presentan ejemplos para ilustrar las conceptos.
Tipo: Ejercicios
1 / 32
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
Autor: Jorge Sánchez (www.jorgesanchez.net) año 2004 e-mail: mailto:[email protected]
Este trabajo está protegido bajo una licencia de Creative Commons del tipo Attribution-NonCommercial-ShareAlike. Para ver una copia de esta licencia visite: http://creativecommons.org/licenses/by-nc-sa/2.0/ o envíe una carta a: Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Esquema Conceptual
Mundo real Esquema canónico
Esquema interno BD Físical
Modelo Lógico Tiene en cuenta el tipo de DBMS a utilizar
Ilustración 1, Posición de esquema canónico dentro de los esquema de creación de una base de datos
El esquema canónico o lógico global, es un esquema que presenta de forma conceptual la estructura de una base de datos. Es un esquema que depende del tipo de DBMS que vayamos a utilizar. Se crea a partir del modelo conceptual (véase el documento Diseño Conceptual de Bases de Datos en www.jorgesanchez.net/bd ). Y serviría para cualquier base de datos comercial del tipo elegido en el esquema (hay esquemas relacionales, en red, jerárquicos,...)
En ellas se organiza la información se organiza con un jerarquía en la que la relación entre las entidades de este modelo siempre es del tipo padre / hijo. De esta forma hay una serie de nodos que contendrán atributos y que se relacionarán con nodos hijos de forma que puede haber más de un hijo para el mismo padre (pero un hijo sólo tiene un padre). Las entidades de este modelo se llaman segmentos y los atributos campos. La forma visual de este modelo es de árbol invertido, en la parte superior están los padres y en la inferior los hijos.
Diseño conceptual de bases de datos
Departamento
Documentos Personal
Tareas
Ilustración 2, Ejemplo de esquema jerárquico
Se trata de un modelo que se utilizó durante mucho tiempo. Organiza la información en registros y enlaces. Los registros representan las entidades del modelo entidad / relación. En los registros se almacenan los datos utilizando atributos. Los enlaces permiten relacionar los registros de la base de datos. El modelo en red más aceptado es el llamado codasyl , que durante mucho tiempo se ha convertido en un estándar. Las bases de datos en red son parecidas a las jerárquicas sólo que en ellas puede haber más de un padre. En este modelo se pueden representar perfectamente relaciones varios a varios. Pero su dificultad de manejo y complejidad hace que se estén abandonando completamente.
Los datos se muestran en forma de tablas y relaciones. Este es el modelo que se comenta en el presente documento. De hecho es el claramente más popular.
Desde la aparición de la programación orientada a objetos (POO u OOP) se empezó a pensar en bases de datos adaptadas a estos lenguajes. En estos lenguajes los datos y los procedimientos se almacenan juntos. Esta es la idea de las bases de datos orientadas a objetos. A través de esta idea se intenta que estas bases de datos consiguen arreglar las limitaciones de las relacionales. Por ejemplo el problema de la herencia, tipos definidos por el usuario, disparadores almacenables en la base de datos, soporte multimedia... Se supone que son las bases de datos de tercera generación (la primera fue las bases de datos en red y la segunda las relacionales), lo que significa que el futuro parece estar a favor de estas bases de datos. Pero siguen sin reemplazar a las relacionales (aunque cada vez hay más). Su modelo conceptual se suele diseñar en UML y el lógico en ODMG 3.
Tratan de ser un híbrido entre el modelo relacional y el orientado a objetos. El problema de las bases de datos orientadas a objetos es que requieren reinvertir de nuevo para convertir las bases de datos. En las bases de datos objeto relacionales se intenta conseguir una compatibilidad relacional dando la posibilidad de integrar mejoras de la orientación a objetos.
Edgar Frank Codd a finales definió las bases del modelo relacional a finales de los 60. Trabajaba para IBM empresa que tardó un poco en implementar sus bases. Pocos años después el modelo se empezó a implementar cada vez más, hasta ser el modelo de bases de datos más popular. En las bases de Codd se definían los objetivos de este modelo:
manipulación lógica
modificadas por que se modifiquen elementos de la base de datos.
usuarios y aplicaciones.
(las tablas)
En 1978, IBM desarrolla el lenguaje QBE. Que aproximaba la idea relacional a sus ficheros VSAM. En 1979 Oracle se convierte en el primer producto comercial DBMS relacional (RDBMS). En 1980 aparece Ingres que utilizaba el lenguaje Quel que implementaba el cálculo relacional.
Año Hecho
1970 Codd publica las bases del modelo relacional
1971-72 Primeros desarrollos teóricos
1973-78 Primeros prototipos
1978 Aparece el lenguaje QBE
1979 Aparece Oracle
1980 Aparece Ingres
1981 Aparece SQL
1982 Aparece DB
1986 ANSI normaliza el SQL (SQL/ANSI)
1987 SQL de ISO
1990 Versión dos del modelo relacional (RM/V2)
1992 SQL 92
1998 SQL 3
Copyright-Copyleft: © Jorge Sánchez 2004
Los dominios suponen una gran mejora en este modelo ya que permiten especificar los posibles valores válidos para un atributo. Cada dominio incorpora su nombre y una definición del mismo. Ejemplos de dominio:
Los dominios pueden ser también compuestos a partir de otros (año, mes y día = fecha)
Conjunto de atributos de una tabla que identifican unívocamente cada tupla de la tabla.
Clave candidata que se escoge como identificador de las tuplas.
Cualquier clave candidata que no sea primaria
Atributo de una tabla relacionado con una clave de otra tabla.
Los valores nulos indican contenidos de atributos que no tienen ningún valor. En claves secundarias indican que el registro actual no está relacionado con ninguno. En otros atributos indica que no se puede rellenar ese valor por la razón que sea. Las bases de datos relacionales admiten utilizar ese valor en todo tipo de operaciones. Eso significa definir un tercer valor en la lógica. Además de el valor verdadero o falso, existe el valor para los nulos. La razón de este tercer valor ambiguo es que comparar dos atributos con valor nulo, no puede resultar ni verdadero, ni falso. De hecho necesitamos definir la lógica con este valor:
Diseño conceptual de bases de datos
Se trata de unas condiciones de obligado cumplimiento por los datos de la base de datos. Las hay de varios tipos.
Son aquellas que no son determinadas por los usuarios, sino que son definidas por el hecho de que la base de datos sea relacional. Por ejemplo:
inscrito
El modelo relacional permite a los usuario incorporar restricciones personales a los datos. Las principales son:
repetir valores.
repetirse.
valor
reflejados en la tabla donde ese atributo es clave primaria.
sea actualizado.
Preocupado por los productos que decían ser sistemas gestores de bases de datos relacionales (RDBMS) sin serlo, Codd publica las 12 reglas que debe cumplir todo DBMS para ser considerado relacional. Estas reglas en la práctica las cumplen pocos sistemas relacionales. Las reglas son:
explícitamente en el esquema lógico. Es decir, todos los datos están en las
nombre de la columna o atributo que contiene el dato.
tratamiento adecuado de estos valores
En principio las entidades fuertes del modelo Entidad Relación son transformados al modelo relacional siguiendo estas instrucciones:
Esto hace que la transformación sea de esta forma:
Nombre
Identificador (^) Atributo
Atributo2 Atributo
Nombre( Identificador, Atributo 1, Atributo 2, Atributo 3)
Ilustración 4 ,Transformación de una entidad fuerte al esquema relacional
La idea inicial es transformar a cada relación en una tabla en el modelo relacional. Pero hay que distinguir según el tipo de relación.
En las relaciones varios a varios, la relación se transforma en una tabla cuyos atributos son: los atributos de la relación y las claves de las entidades relacionadas (que pasarán a ser claves externas). La clave de la tabla la forman todas las claves externas:
Nombre
Atributo
Identificador1 (^) Atributo1 Identificador
Nombre(Identificador1,Identificador2 ,Atributo1,Atributo2)
Ilustración 5, Transformación de una relación varios a varios
Copyright-Copyleft: © Jorge Sánchez 2004
identificador2. En otro caso no se podrán permitir (ya que siempre habrá un valor relacionado). En el caso de las relaciones uno a uno, ocurre lo mismo: la relación no se convierte en tabla, sino que se coloca en una de las tablas (en principio daría igual cuál) el identificador de la entidad relacionada como clave externa. En el caso de que una entidad participe opcionalmente en la relación, entonces es el identificador de ésta el que se colocará como clave externa en la tabla que representa a la otra entidad.
Las relaciones recursivas se tratan de la misma forma que las otras, sólo que un mismo atributo puede figurar dos veces en una tabla como resultado de la transformación:
Relac.
Identificador
Atributo 1 (^) Rol
Rol
Entidad( Identificador,Atributo1,Identificador Rol 1)
Relac.
Identificador
Atributo 1 (^) Rol
Rol
Entidad( Identificador,Atributo1) Relac(Identificador Rol 1, Identificador Rol 2 ,Atributo1)
Ilustración 8, Transformación de relaciones recursivas en el modelo relacional
Toda entidad débil incorpora una relación implícita con una entidad fuerte. Esta relación no necesita incorporarse como tabla en el modelo relacional. Sí se necesita incorporar la clave de la entidad fuerte como clave externa en la entidad débil. Es más, normalmente esa clave externa forma parte de la clave principal de la tabla que representa a la entidad débil. El proceso es:
Id Fuerte
Entidad Fuerte
Atributo
Id Débil
Entidad Débil
Atributo
Entidad1( Id Débil Id Fuerte,, Atributo2)
Entidad Fuerte( Id Fuerte, Atributo 1)
Ilustración 9, transformación de una entidad débil en el modelo relacional
Diseño conceptual de bases de datos
En ocasiones el identificador de la entidad débil es suficiente para identificar los ejemplares de dicha entidad, entonces ese identificador quedaría como clave principal, pero el identificador de la entidad fuerte seguiría figurando como clave externa en la entidad débil.
Las generalizaciones y/o especificaciones se convierten al modelo relacional de esta forma:
el identificador de la superentidad en cada subentidad como clave externa:
Id1 (^) Atributo
Id
Atributo
Id
Atributo
Subentidad1( Id2, Atributo 2, Id1)
Subentidad2( Id3, Atributo 3, Id1)
Superentidad( Id1, Atributo 1)
Ilustración 10, Proceso de transformación de relaciones ISA con clave propia
como identificador:
Superentidad
Subentidad1 Subentidad
Id (^) Atributo
Id
Atributo
Id
Atributo
Subentidad1( Id,Atributo 2)
Subentidad2( Id, Atributo 3)
Superentidad(Id , Atributo 1)
Ilustración 11, Proceso de transformación de relaciones ISA en el modelo relacional si tienen la misma clave
