0% encontró este documento útil (0 votos)
45 vistas6 páginas

Tema X

El documento aborda las restricciones en bases de datos relacionales, clasificándolas en implícitas y explícitas, así como semánticas y funcionales. Se detallan las restricciones de dominio, clave, valores Null, integridad de entidad e integridad referencial, explicando su importancia y aplicación en el diseño de bases de datos. Se basa en el libro 'Fundamentos de Sistemas de Bases de Datos' de R. Elmasri y S. B. Navathe.

Cargado por

crsindoni
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
45 vistas6 páginas

Tema X

El documento aborda las restricciones en bases de datos relacionales, clasificándolas en implícitas y explícitas, así como semánticas y funcionales. Se detallan las restricciones de dominio, clave, valores Null, integridad de entidad e integridad referencial, explicando su importancia y aplicación en el diseño de bases de datos. Se basa en el libro 'Fundamentos de Sistemas de Bases de Datos' de R. Elmasri y S. B. Navathe.

Cargado por

crsindoni
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

Tema X 1

Base de Datos I - Curso 2do año EMT Informática


Prof.: Cinthia Costa

Tema X

Conceptos a abordar en este material

● Restricciones
○ Implícitas - Basadas en el modelo
○ Explícitas . Basadas en el esquema
■ De Dominio
■ De Clave
■ De valores Null
■ De integridad de entidad
■ De integridad referencial
○ Semánticas
○ Funcionales

Restricciones del modelo relacional y esquemas de bases de datos relacionales

Categorías:
● Restricciones implícitas o inherentes basadas en el modelo: por ejemplo, cuando vimos que
el orden de las tuplas no define una relación o que las relaciones no pueden tener tuplas
repetidas, etc. Son las reglas propias del modelo.
● Restricciones explícitas o basadas en el esquema: que pueden expresarse directamente en los
esquemas del modelo de datos mediante la utilización del lenguaje de definición de datos
(DDL).
○ De dominio
○ De clave
○ De valores Null

Material basado en el libro “Fundamentos de Sistemas de Bases de Datos” R. Elmasri y S. B. Navathe. PEARSON EDUCACIÓN S.A Madrid. 2007
Tema X 2
Base de Datos I - Curso 2do año EMT Informática
Prof.: Cinthia Costa
○ De integridad de entidad
○ De integridad referencial
● Restricciones semánticas o basadas en las reglas del negocio: No pueden expresarse
directamente en los esquemas del modelo de datos, por eso deben ser expresadas e
implementadas por los programas.
● Restricciones de dependencia de datos: Se emplean para comprobar la corrección del diseño
de una base de datos relacional.
○ Restricciones de dependencia funcionales
○ Restricciones de dependencia multivalor

Veremos cada una de las restricciones basadas en el esquema.

De dominio
Los valores de los atributos deben ser un valor atómico que pertenezca al dominio del atributo. Los
tipos de datos asociados a cada atributo pueden ser valores numéricos estandar para datos enteros
(entero corto, entero o entero largo) y reales (de coma flotante simple y de doble precisión).
También se puede almacenar caracteres, tipos de datos lógicos, cadenas de longitud fija y variable,
fechas, horas y monedas; también se pueden definir tipos de datos ennumerados en el que todos sus
valores estén explicitados. Depende mucho del tipo de DBSM, pero por lo general todos comparten
estas definiciones de datos.

De clave
Si definimos una relación como un conjunto de tuplas, debemos saber que en los conjuntos no hay
elementos repetidos, por tanto en una relación no puede haber tuplas repetidas. Siempre el conjunto
de todos los atributos de una relación permite diferenciar una tupla de otra, y este conjunto recibe el
nombre de superclave, pero no necesariamente deben ser todos los atributos, puede ser un
subconjunto de ellos que también permita diferenciar una tulpa de otra.
Por ejemplo, en la relación ESTUDIANTE, los atributos (Nombre, Dni, TlfParticular, Dirección,
TlfTrabajo, Edad, Mnc) forman una superclave porque es la superclave por defecto, el conjunto de
todos los atributos, pero también los atributos (Nombre, Dni, TlfParticular) porque siempre van a
tener valores distintos para cada tupla, y también (Nombre, Dni) es una superclave.

Material basado en el libro “Fundamentos de Sistemas de Bases de Datos” R. Elmasri y S. B. Navathe. PEARSON EDUCACIÓN S.A Madrid. 2007
Tema X 3
Base de Datos I - Curso 2do año EMT Informática
Prof.: Cinthia Costa
El mínimo conjunto de atributos que permite diferenciar una tupla de la otra recibe el nombre de
clave. Esto es, como la clave primaria en el MER o EER, un atributo que cuyos valores sean únicos
para cada tupla. En el caso de ESTUDIANTE la clave es Dni porque sabemos que nunca va a tomar
valores iguales en cada tupla.
También podemos tener otras claves dentro de una relación, le llamamos claves candidatas, porque
para esos atributos cada tupla toma valores diferentes, es decir, que también nos permiten
identificar una tupla de otra. La idea es elegir dentro de las claves candidatas la que vamos a tomar
como clave principal de la relación.
Finalmente debemos saber que a veces la clave no está definida por un sólo atributo, recordemos
que la definición de clave es el subconjunto mínimo de atributos que toman valores únicos para
cada tupla. Entonces, este subconjunto se puede formar por un atributo sólo o a veces por varios. En
este caso debemos subrayar cada uno de los atributos que forman parte de la clave.

De valores Null
Con respecto a la declaración de Null para los valores de los atributos, se utilizan en casos que no se
conoce el valor o no aplica para un caso particular. Por ejemplo si tenemos un atributo que es
Pasaporte dentro de estudiante, hay algunos estudiantes que lo tienen y se puede escribir su número,
pero otros que no, por lo que en ese caso podríamos Null. Es recomendable no utilizar el valor Null
dentro de las relaciones, porque pueden arrojar resultados inadecuados en ciertas consultas.
Tratemos de evitarlos lo más posible. Dentro del DBMS tenemos la opción de registrar un atributo
como NOT NULL, es decir, no permitimos que adquiera nunca el valor Null.

De integridad de entidad
Esta restricción declara que ningún valor de una clave primaria puede ser Null. Esto tiene sentido ya
que el atributo que funcione como clave primaria tiene la utilidad de identificar entidades de una
relación, por lo que si permitimos que sea Null no podremos identificar la entidad.

Material basado en el libro “Fundamentos de Sistemas de Bases de Datos” R. Elmasri y S. B. Navathe. PEARSON EDUCACIÓN S.A Madrid. 2007
Tema X 4
Base de Datos I - Curso 2do año EMT Informática
Prof.: Cinthia Costa
De integridad referencial
Esta restricción vincula a dos relaciones. En una base de datos como la que aparece en la imagen de
más abajo vamos a ver que hay atributos que guardan el mismo dato, pero se encuentran en distintas
relaciones, por ejemplo: Observemos el atributo NumDpto, aparece tanto en la relación
DEPARTAMENTO como en LOCALIZACIONES_DPTO, y esto es porque se refiere al mismo
aspecto de la realidad, es decir, al número que se asigna a un departamento. En ese caso el atributo
tiene el mismo nombre en ambas relaciones, por lo que es sencillo darnos cuenta que se refiere al
mismo aspecto del mundo real, sin embargo puede pasar que tenga nombres distintos en distintas
relaciones, como Dno en EMPLEADO y NumDptoProyecto en PROYECTO. Aquí vemos que los
atributos que guardan el mismo dato en relaciones distintas pueden o no tener el mismo nombre.
También sucede que distintos atributos se llamen igual pero guarden datos del mundo real
diferentes, por ejemplo si se hubiera utilizado “nombre” para el nombre del empleado y “nombre”
para el nombre del departamento. En casos donde un atributo representa el mismo dato del mundo
real pero se encuentra en distintas relaciones tenemos que observar que en una de ellas ese atributo
funciona como clave primaria, mientras que en la otra relación funciona como clave foránea o
foreign key (FK). Entonces se establece una referencia entre las tablas, donde el atributo que
aparece en la segunda relación es una referencia a la clave primaria de otra relación. Por ejemplo,
en PROYECTO el atributo NumDptoProyecto es clave foránea porque hace referencia al atributo
NumeroDpto que es clave primaria en DEPARTAMENTO.
Es importante aclarar que no necesariamente las claves foráneas se establecen desde relaciones
diferentes. Observen el caso de EMPLEADO con el atributo Dni y SuperDni. En SuperDni se
guardan los Dni de los supervisores, pero los supervisores también son empleados, por lo que con
superDni se hace referencia al atributo que es clave primaria en la misma relación, o sea al Dni.
Esta restricción forma parte de la definición de datos, y debe ser aplicada para que el DBMS las
incorpore.

Material basado en el libro “Fundamentos de Sistemas de Bases de Datos” R. Elmasri y S. B. Navathe. PEARSON EDUCACIÓN S.A Madrid. 2007
Tema X 5
Base de Datos I - Curso 2do año EMT Informática
Prof.: Cinthia Costa
Claves foráneas de la base de datos Empresa
Las puntas de flecha indican el atributo referenciado, mientras que el otro extremo de la flecha
indica el atributo del que proviene la referencia.

Esquema de la base de datos relacional EMPRESA.

Material basado en el libro “Fundamentos de Sistemas de Bases de Datos” R. Elmasri y S. B. Navathe. PEARSON EDUCACIÓN S.A Madrid. 2007
Tema X 6
Base de Datos I - Curso 2do año EMT Informática
Prof.: Cinthia Costa
Estado de la base de datos relacional EMPRESA

Material basado en el libro “Fundamentos de Sistemas de Bases de Datos” R. Elmasri y S. B. Navathe. PEARSON EDUCACIÓN S.A Madrid. 2007

También podría gustarte