• Author / Uploaded
• DIEGO ALDAHIR MU�OZ NARANJO

Citation preview

TECNOLÓGICO NACIONAL DE MÉXICO CAMPUS CUAUTLA

FUNDAMENTOS DE BASE DE DATOS

LUIS ADRIAN GRACÍA GARCÍA

INVESTIGACIÓN UNIDAD 3 GRUPO 1 EQUIPO 4

García López Blas Francisco 19680152 Torres Gonzalez Elid Ailton 19680267 Ponce Mocha Dexter 19680227 Cardenas Villarruel Alonso Eliseo 19680118 Galindo Guerrero Luis Iván 19680150 Marín Huerta Favio Daniel 19680186 Muñoz Naranjo Diego Aldahir 19680208 Castro Arellano Angel Emanuel 19680124 Rivera Ferrer Oscar Alberto 19680237

16/NOV/2020

INTRODUCCIÓN El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que el modelo relacional se base en la teoría matemática lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las matemáticas proporcionan los elementos básicos necesarios para la creación de una base datos relacional bien estructurada y aportan ideas para establecer un buen método de diseño. La teoría matemática proporciona la base para el modelo relacional, de modo que el modelo sea predecible, confiable y seguro. La teoría describe los elementos básicos que se utilizan para crear una base de datos relacional y proporciona pautas para establecer una base de datos. La organización de estos elementos para lograr el resultado deseado se llama diseño.

3.1 Introducción al Modelo Relacional ¿Qué es un Modelo? Cuando en teoría de diseño de bases de datos se emplea el término "modelo" , esto no tiene el mismo significado que en Lógica . En Lógica por "modelo" se entiende una interpretación en la que se satisfacen ( se evalúan como ciertas ) las fórmulas de una teoría , lo que asegura su consistencia . En Bases de Datos , un Modelo es un formalismo que nos permite representar la realidad y , más concretamente , aquella parte de la realidad que nos interesa ( Una Empresa , una Universidad , una Biblioteca , el catálogo de las especies protegidas en un determinado país... ). Las partes fundamentales de un Modelo , son : • Estructura de datos • Restricciones • Operadores asociados El modelo relacional se ha establecido actualmente como el principal modelo de datos para las aplicaciones de procesamiento de datos. Debido a su simplicidad, Facilita el trabajo del programador y una base de datos relacional consiste en un conjunto de tablas. El principal objetivo del modelo de datos relacional es facilitar que la base de datos sea percibida o vista por el usuario como una estructura lógica que consiste en un conjunto de relaciones y no como una estructura física de implementación. Esto ayuda a conseguir un alto grado de independencia de los datos. Un objetivo adicional del modelo es conseguir que esta estructura lógica con la que se percibe la base de datos sea simple y uniforme. Con el fin de proporcionar simplicidad y uniformidad, toda la información se representa de una única manera: mediante valores explícitos que contienen las relaciones (no se utilizan conceptos como por ejemplo apuntadores entre las relaciones). Con el mismo propósito, todos los valores de datos se consideran atómicos; es decir, no es posible descomponerlos. Hay que precisar que un SGBD relacional, en el nivel físico, puede emplear cualquier estructura de datos para implementar la estructura lógica formada por las relaciones. En particular, a nivel físico, el sistema puede utilizar apuntadores, índices, etc. Sin embargo, esta implementación física queda oculta al usuario. En los siguientes apartados estudiaremos la estructura de los datos, las operaciones y las reglas de integridad del modelo relacional. Hay dos formas posibles de enfocar el estudio de los contenidos de este módulo. La primera consiste en seguirlos en orden de exposición. De este modo, se van tratando todos los elementos de la teoría del modelo relacional de forma muy precisa y en un orden lógico. Otra posibilidad, sin embargo, es empezar con la lectura del resumen final del módulo y leer después todo el resto de los contenidos en el orden normal. El resumen describe los aspectos más relevantes de la teoría relacional que se explican y, de este modo, proporciona una visión global de los contenidos del módulo que, para algunos estudiantes, puede ser útil comprender antes de iniciar un estudio detallado.

Estructura de datos en el Modelo Relacional.

El Modelo Relacional fue propuesto por E.Codd en 1970 ( E. Codd era entonces un investigador del Centro de IBM en San José (California ) y publicó su propuesta en un artículo fundamental que obtuvo el ACM Award correspondiente al Congreso VLDB de 1970 ) . La estructura subyacente básica es la relación , entendida en su acepción matemática básica : Un subconjunto de un producto cartesiano de conjuntos . Cuando se pretende describir una parcela de la realidad mediante el formalismo relacional, el primer paso es discernir los atributos presentes en el problema. Un atributo es un ítem elemental de información, en el sentido de no poder desglosarse en componentes más simples. Los atributos son los nombres que damos a las propiedades de los objetos acerca de los cuales se va a guardar información.

3.2 Conversión de Modelo E-R a Modelo Relacional Así como existe una relación entre una clase de un diagrama de clases y el código, también existe una relación entre una entidad (o un vínculo) de un diagrama ERE o una clase y el modelo relacional. El modelo ER es un modelo de datos conceptual de alto nivel. ● Facilita las tareas de diseño conceptual de bases de datos. ● Es necesario traducirlo a un esquema que sea compatible con un SGBD. ● El Modelo Relacional es utilizado por la mayoría de los SGBD existentes en el mercado.

Transformación del Modelo ER al Modelo Relacional (Básico)

● Modelo Entidad Relación (Básico), transformación al modelo Relacional de: – Entidades (no débiles) – Entidades Débiles – Vínculos 1:N – Vínculos 1:1 equivalentes – Vínculos M:N – Atributos Multivaluados – Vínculos n-arios

Definir una serie de esquemas de relaciones

1. Transformación de Entidades

Persona cedula primNombre primApellido segApellido telefono

Empleado (Cédula, PrimNombre, PrimApellido, SegApellido, Teléfono)

Clave Primaria

Atributo compuesto Nombre

En caso de que más de un atributo sea parte de la clave primaria:

Proyecto numero nombre descripcion

Proyecto (Número_Proyecto, Nombre_Proyecto, Descripción_Proyecto)

CP compuesta

• • • •

Para cada tipo normal (no débil) de entidad E del modelo ERE se define una relación R. En la relación R se incluyen todos los atributos simples de E. Se incluyen en R los atributos simples que sean componentes de los atributos compuestos. Se eligen todos los atributos clave de E como atributos claves de R.

2. Transformación de Entidades Débiles

Hito (Número_Proyecto, Nombre_Proyecto, Codigo_Hito, Fecha_Hito, Descripción_Hito)

Proyecto (Número_Proyecto, Nombre_Proyecto, Descripción_Proyecto) Como composición se vería así: Proyecto numero nombre descripcion

• • •

es_parte_de

1

1…*

Hito codigo fecha descripcion

Para cada entidad débil D del modelo ER y su respectivo vínculo con su entidad propietaria E se define una relación R. La relación R tiene todos los atributos de la entidad débil D más los atributos que conforman la clave primaria de la entidad propietaria E. La clave primaria de la relación R está formada por los atributos de la clave primaria de la entidad propietaria E más los atributos de la clave parcial de D.

3. Transformación de Vínculos 1:N

Empleado(Cédula, PrimNombre,PrimApellido, SegApellido, Teléfono, Numero_Dpto)

Departamento (Numero_Dpto, Nombre_Dpto)

Como composición se vería así: Empleado cedula primNombre PrimApellido SegApelllido telefono •

pertenece_a

0…*

Departamento numero nombre 1

Para cada vinculo 1:N entre dos entidades (no débiles) E y F donde F está del lado N del vínculo, se añade a la relación correspondiente a la entidad F de alguna de las entidades la clave primaria de la otra entidad relacionada.

4. Transformación de Vínculos 1:1

Departamento (Número_Dpto, Nombre_Dpto, Cédula_Jefe) Empleado (Cédula, PrimNombre, PrimApellido, SegApellido, Teléfono)

Empleado cedula primNombre PrimApellido SegApelllido telefono •

•

Tiene_jefe

1

Departamento numero nombre 1

Para cada vinculo 1:1 entre dos entidades (no débiles) E y F se añade a la relación de alguna de las entidades, a modo de clave foránea, la clave primaria de la otra entidad relacionada. Se especifica una restricción que define que la clave foránea añadida debe ser única (no se puede repetir, porque de hacerlo entonces sería una relación 1:N

5. Transformación de Vínculos M:N ¿Cuantas veces puede un empleado trabajar en un proyecto? O bien, ¿Cuántos registros puedo tener en Trabaja En para un mismo empleado y proyecto?

Empleado (cedula, PrimNombre, PrimApellido, SegApellido, Teléfono)

Trabaja_en (cedula, numero_Proyecto, Horas)

Proyecto (Número_Proyecto, Nombre_Proyecto)

Empleado cedula primNombre PrimApellido SegApelllido telefono

Proyecto numero nombre 0 …*

0 …*

Trabaja_en Horas • • •

Para cada vinculo M:N entre dos entidades se crea una relación R. Los atributos de la relación R serán las claves primarias de las entidades relacionadas más los atributos propios del vínculo. La clave primaria de la relación R será el conjunto de todos los atributos que sean claves primarias de las entidades relacionadas.

6. Transformación de Atributos Multivaluados

Lugares_Dptos (Numero_Dpto, Lugar) Departamento (Número_Dpto, Nombre_Dpto)

• • •

Para cada atributo multivaluado se creará una relación R. Los atributos de la relación R serán la clave primaria de las entidad a la cual pertenece el atributo multivaluado más el (o los) atributos correspondientes al atributo multivaluado. La clave primaria de la relación R será la clave primaria de la entidad a la cual pertenece el atributo multivaluado más el (o los) atributos correspondientes al atributo multivaluado

7. Transformación de Vínculos n-arios

Presta (Numero_Dpto, Codigo_Servicio, RIF, Fecha)

Presta fecha Departamento numero nombre

0 …*

0 …*

Cliente RIF nombre

1 Servicio codigo nombre

• • •

Para cada vinculo M:N entre tres o más entidades se crea una relación R. Los atributos de la relación R serán las claves primarias de todas las entidades relacionadas más los atributos propios del vinculo. La clave primaria de la relación R será el conjunto de todos los atributos que sean claves primarias de todas las entidades relacionadas.

Transformación del Modelo ERE al Modelo Relacional (Extendido) Transformación al modelo Relacional de: – Generalización (o Especialización) – Categorización

Definir una serie de esquemas de relaciones equivalentes

8. Transformación de una Generalización

Usando un diagrama de clases...

Existen cuatro estrategias para transformar una relación de generalización (o especialización) al modelo Relacional: •

Estrategia 1: Crear una relación R para la entidad padre E y una relación Ri para cada entidad especializada Ei. – La relación R tiene todos los atributos de la entidad E. – Cada relación Ri tiene todos los atributos de la entidad Ei correspondiente. – – Todas las relaciones (tanto R como cada Ri ) comparten la misma clave primaria de la entidad padre E. Persona (Cédula, Nombre, Apellido, Dirección) Empleado (Cédula, Salario) Estudiante (Cédula, Carrera) Profesor (Cédula, Costo_Hora)

Esta estrategia funciona tanto para subclases que se traslapan como para subclases disjuntas y para especializaciones totales o parciales. Persona Empleado Estudiante

•

Estrategia 2: Crear una relación Ri para cada entidad especializada Ei . – Cada relación Ri tiene todos los atributos de la entidad Ei correspondiente más los atributos de la entidad padre E. – La clave primaria de cada relación Ri es la clave primaria de la entidad padre E.

Empleado (Cédula, Nombre, Apellido, Dirección, Salario) Profesor (Cédula, Nombre, Apellido, Dirección, Costo_Hora) Estudiante (Cédula, Nombre, Apellido, Dirección, Carrera)

•

Estrategia 3: Utilizar una misma relación R para la entidad padre E y para las entidades especializadas Ei . – La relación R tiene todos los atributos de la entidad padre E más todos los atributos todas las entidades especializadas Ei . – Se crea un atributo adicional que define el “tipo” de entidad Ei que representa una tupla en particular. – Aplica sólo a casos donde las subclases son disjuntas.

Persona (Cédula, Nombre, Apellido, Direccion,Tipo, Salario, Costo_Hora, Carrera)

Donde Tipo puede ser 0 para la subclase Empleado, 1 para la subclase Profesor o 2 para la subclase Estudiante

•

Estrategia 4: Utilizar una misma relación R para la entidad padre E y para las entidades especializadas Ei . (Similar a la estrategia 3). – La relación R tiene todos los atributos de la entidad padre E más todos los atributos todas las entidades especializadas Ei . (Similar a 3) – Se crea un atributo booleano adicional por cada entidad especializada que define si una tupla en particular pertenece dicha entidad

Persona (Cédula, Nombre, Apellido, Dirección, Es_Empleado, Salario, Es_Profesor, Costo_Hora, Es_Estudiante, Carrera) Los atributos “Es_*” son verdaderos para una tupla si esta es una la clase especializada de la entidad correspondiente

9. Transformación de una Categorización

Existen dos casos posibles al transformar una relación de categorización al modelo Relacional •

Caso 1: Las superclases de la categoría tienen diferentes claves primarias. – Se crea una relación R que corresponda a la categoría y se asigna una clave sustituta arbitraria. – Se añade la clave sustituta a modo de clave foránea a cada una de las relaciones Ri que correspondan a las superclases de la categoría.

Claves primarias de las superclases no compatibles

Persona (Cédula, Nombre, Apellido, Dirección, IdCuentaHabiente) Compañía (RIF, Nombre, IdCuentaHabiente) CuentaHabiente (IdCuentaHabiente)

•

Caso 2: Las superclases de la categoría tienen la misma clave primaria. – Se crea una relación R que corresponda a la categoría y se le asigna como atributo de clave primaria la clave común a todas las superclases de la categoría.

Claves primarias compatibles entre las superclases

Vehículo_Registrado (Matrícula) Auto (Matrícula, MarcaA, ModeloA, Color) Camión (Matrícula, ModeloC, NumEjes, Peso)

Se transforma al modelo relacional de la siguiente forma:

3.3 Esquema de la base de datos Relacional El término "esquema de base de datos" (en inglés Database Schema) puede referirse a una representación visual de una base de datos, a un conjunto de reglas que rige una base de datos, o bien, a todo el conjunto de objetos que pertenecen a un usuario en particular. Se especifica mediante un conjunto de definiciones expresadas mediante un lenguaje especial llamado lenguaje de definición de datos (LDD). Los esquemas son raramente modificados, si es que lo son alguna vez. Un esquema de base de datos corresponde a las declaraciones de variables (junto con definiciones de tipos asociadas) en un programa. Cada variable tiene un valor particular en un instante de tiempo. Los valores de las variables en un programa en un instante de tiempo corresponden a un ejemplar de un esquema de bases de datos. Los sistemas de bases de datos tienen varios esquemas divididos de acuerdo a los niveles de abstracción. Esquema Conceptual: El esquema especifica todos los conjuntos de entidades, conjuntos de relaciones, atributos y restricciones de correspondencia. El diseñador revisa el esquema para confirmar que todos los requisitos de datos se satisfacen realmente y no hay conflictos entre sí. También se examina el diseño para eliminar características redundantes. Esquema Lógico: Es un mapa de las entidades y sus atributos y las relaciones. El diseñador traduce el esquema conceptual de alto nivel al modelo de datos de la implementación del sistema de base de datos que se usará. El diseñador usa el esquema resultante específico a la base de datos en la siguiente fase. Esquema Físico: Es una aplicación de un esquema lógico. Se especifican las características físicas de la base de datos. Estas características incluyen la forma de organización de los archivos y las estructuras de almacenamiento interno. De éstos, el esquema lógico es con mucho el más importante, en términos de su efecto en los programas de aplicación, ya que los programadores construyen las aplicaciones usando el esquema lógico. El esquema físico está oculto bajo el esquema lógico, y puede ser fácilmente cambiado usualmente sin afectar a los programas de aplicación. Los programas de aplicación se dice que muestran independencia física de datos si no dependen del esquema físico y, por tanto, no deben ser modificados si cambia el esquema físico. En general, los esquemas de las relaciones incluyen una lista de los atributos y de sus dominios correspondientes. La definición exacta del dominio de cada atributo no será relevante hasta que se discuta el lenguaje SQL. Suele ser almacenado en un Diccionario de Datos. Aunque generalmente el esquema es definido en un lenguaje de Base de datos, el término se usa a menudo para referirse a una representación gráfica de la estructura de base de datos.

3.4 Restricciones Las restricciones son limitaciones que deseamos imponer en nuestro sistema, de forma que sea imposible almacenar datos incorrectos. Por ejemplo, la limitación de los valores posibles de los atributos a un subconjunto, lo que denominábamos dominio del atributo. •

Restricciones de integridad

Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la pérdida de la consistencia de los datos. Protegen a la base de datos contra los daños accidentales. Tipos de restricciones de integridad: Declaración de claves (primarias, candidatas). Cardinalidad de la relación – de varios a varios, de uno a varios, de uno a uno. Participación mín/máx. Restricciones de los dominios. Integridad referencial. Dependencias funcionales. Dependencias multivaloradas. Los asertos y disparadores permiten implementar restricciones de integridad. •

Restricciones de los dominios

Las restricciones de los dominios no sólo permiten verificar los valores introducidos en la base de datos sino también examinar las consultas para asegurarse de que tengan sentido las comparaciones que hagan.

3.4.1 Integridad de entidad Se basa en que la clave primaria dispone que los atributos de la clave primaria de una relación no pueden tener valores nulos. Ejemplo: DESPACHOS Edificio

Número

Superficie

----------

120

10

Marina

122

15

Marina

230

20

Diagonal

120

10

Si un despacho tuviese un valor nulo para edificio porque en un momento dado el nombre de este edificio no se conoce, no podríamos estar seguros de que el valor desconocido de edificio no es ni Marina ni Diagonal. Esta regla es necesaria para que los valores de las claves primarias puedan identificar las tuplas individuales de las relaciones. Si las claves primarias tuviesen valores nulos, es posible que algunas tuplas no se pudieran distinguir.

A continuación, definimos esta regla de forma más precisa: - La regla de integridad de entidad de la clave primaria establece que, si el conjunto de atributos CP es la clave primaria de una relación R, la extensión de R no puede tener ninguna tupla con algún valor nulo para alguno de los atributos de CP. Un SGBD relacional tendrá que garantizar el cumplimiento de esta regla de integridad en todas las inserciones y, también, en todas las modificaciones que afecten a atributos que pertenecen a la clave primaria de la relación.

3.4.2 Integridad referencial Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la pérdida de la consistencia de los datos. Por tanto, las restricciones de integridad protegen a la base de datos contra los daños accidentales. Una base de datos contiene unos datos que, en cada momento, deben reflejar la realidad o, más concretamente, la situación de una porción del mundo real. En el caso de las bases de datos dato relacionales, esto significa que las tuplas o filas que contienen las relaciones deben tener valores que reflejen la realidad correctamente. Las restricciones de integridad referencial están especificadas entre dos relaciones y se utilizan para mantener la consistencia entre las tuplas de dos relaciones. Informalmente, las restricciones de integridad referencial dicen que una tupla de una relación que hace referencia a otra relación debe hacer referencia a una tupla existente de esa relación. La regla de integridad referencial está relacionada con el concepto de clave foránea. Concretamente, determina que todos los os valores que toma una clave foránea deben ser valores nulos o valores que existen en la clave primaria que referencia. Un SGBD relacional tendrá que hacer cumplir esta regla de integridad. Deberá efectuar comprobaciones cuando se produzcan las siguientes operaciones: • • • •

Inserciones en una relación que tenga una clave foránea. Modificaciones que afecten a atributos que pertenecen a la clave foránea de una relación. Borrados en relaciones referenciadas por otras relaciones. Modificaciones que afecten a atributos que pertenecen a la clave primaria de una relación referenciada por otra relación.

3.5 Integridad de dominio La regla de integridad de dominio está relacionada, como su nombre indica, con la noción de dominio. Esta regla establece dos condiciones. La primera condición consiste en que un valor no nulo de un atributo Ai debe pertenecer al dominio del atributo Ai; es decir, debe pertenecer a dominio(Ai). Esta condición implica que todos los valores no nulos que contiene la base de datos para un determinado atributo deben ser del dominio declarado para dicho atributo. Recordemos que los dominios pueden ser de dos tipos: predefinidos o definidos por el usuario. Observad que los dominios definidos por el usuario resultan muy útiles, porque nos permiten determinar de forma más específica cuáles serán los valores admitidos por los atributos. Esta segunda condición sirve para establecer que los operadores que pueden aplicarse sobre los valores dependen de los dominios de estos valores; es decir, un operador determinado sólo se puede aplicar sobre valores que tengan dominios que le sean adecuados. Las restricciones permiten definir el modo en que SQL Server automáticamente fuerza la integridad de la base de datos. En estas se definen reglas indicando los valores permitidos en las columnas y son el mecanismo estándar para asegurar integridad. Usar restricciones es preferible a usar desencadenadores, reglas o valores por defecto. El query optimizer (optimizador de consultas) de SQL Server utiliza definiciones de restricciones para construir planes de ejecución de consultas de alto rendimiento. Se puede asegurar la integridad de dominio restringiendo el tipo (a través de tipos de datos), el formato (a través de las restricciones CHECK y de las reglas).

CONCLUSIÓN En esta unidad, podemos entender que el modelo relacional es un proceso que se debe llevar a cabo en el desarrollo de la base de datos y debe ser considerado porque nos muestra el tipo de relación que tenemos, la cardinalidad y el tipo de clave que contiene. La función del modelo relacional es ganar un buen control del sistema entendiendo cómo aplicar el modelo de relación de entidades y la cardinalidad correspondiente a cada tabla. Otro punto a destacar es que también sabemos aplicar y aprender conceptos como entidad, atributo y llave para así utilizar estos dentro de la tabla.

REFERENCIAS ABRAHAM SILBERSCHATZ. (2006). FUNDAMENTOS DE BASES DE DATOS (5ª ED.). ESPAÑA: S.A. MCGRAW-HILL. Rafael Camps Paré, Luis Alberto Casillas Santillán. (2005). Bases de datos. Av. Tibidabo, 39-43, 08035 Barcelona: Eureca Media, SL. ELMASRI, R. (2007). Fundamentos de Sistemas de Bases de Datos. Madrid: PEARSON EDUCACIÓN. Silberschatz, A. (2002). FUNDAMENTOS DE BASES DE DATOS. Madrid: McGRAW-HILL. Integridad de dominio. (2010, 30 enero). RAHSuarez’s Blog. https://rahsuarez.wordpress.com/2010/01/05/integridad-de-dominio-restriccionescheck/#:%7E:text=La%20integridad%20de%20dominio%20es,de%20la%20base%20de%20dat os.&text=Usar%20restricciones%20es%20preferible%20a,reglas%20o%20valores%20por%20d efecto/

UNIDAD 3 MODELO RELACIONAL. (2019, 20 mayo). modeloer2.blogspot.com. https://modeloer2.blogspot.com/2019/05/25-la-notacion-e-r-conuml.htmlhttps://modeloer2.blogspot.com/2019/05/25-la-notacion-e-r-con-uml.html

Jorge Sánchez, [Unidad 3] El Modelo Relacional, consultado el 15/11/2020, disponible en: https://funbasedato.blogspot.com/2019/11/unidad-3-modelo-relacional.html https://www.dataprix.com/es/bases-datos-master-software-libre-uoc/1-introduccion-al-modelorelacional http://pegaso.ls.fi.upm.es/BD/Documentacion/MR-Introduccion.pdf Oppel, A. (2010). Fundamentos de bases https://elibro.net/es/lc/cuautla/titulos/37322

de

datos.

McGraw-Hill

Interamericana.