Integridad y seguridad

Informática aplicada

Contenido

• Restricciones de dominio

• Integridad referencial

• Asertos

• Disparadores

• Seguridad y autorización

• Autorización en SQL

Restricciones de dominioLa claúsula create domain crea un nombre de dominio, ej.:

create domain Euros numeric(12,2)

create domain Dólares numeric(12,2)

Se puede usar un dominio por otro. Por ejemplo si el atributo A de r es de tipo Euros se puede convertir mediante:

cast r.A as Dólares

Claúsula checkuna cláusula check puede asegurar que un dominio de sueldo por hora sólo permita valores mayores que un valor especificado

create domain sueldo-por-hora numeric(5,2)constraint comprobación-valor-sueldocheck(value ≥ 4.00)

La cláusula check también puede utilizarse para restringirun dominio para que no contenga valores nulos,como se muestra aquí:

create domain número-cuenta char(10)constraint comprobación-número—cuenta-nulocheck(value not null)

En este otro ejemplo el dominio se puede limitar paraque contenga sólo un conjunto especificado de valoresusando la cláusula in:

create domain tipo-cuenta char(10)constraint comprobación-tipo-cuentacheck(value in (‘Corriente’, ‘Ahorro’))

Una restricción se podría especificar sobre la relación préstamo:

check (nombre-sucursal in(select nombre-sucursal from sucursal))

Integridad referencial

A menudo se desea asegurar que un valor que aparece en una relación para un conjunto de atributos determinado aparezca también en otra relación para un cierto conjunto de atributos. Esta condición se denomina integridad referencial.

Conceptos básicosConsidérese un par de relaciones r (R) y s (S) y la reuniónnatural r |X| s. Puede haber una tupla tr de r que no se reúna con ninguna tupla de s. Es decir, no hay ningún ts en s tal que tr [R ∩ S] = ts [R ∩ S]. Estas tuplas se denominan colgantes.

Sean r1(R1) y r2(R2) dos relaciones con las claves primarias K1 y K2, respectivamente. Se dice que un subconjunto α de R2 es una clave externa que hace referencia a K1 de la relación r1 si se exige que para cada t2 de r2 haya una tupla t1 de r1 tal que t1[K1] = t2[α].

Las exigencias de este tipo se denominan restricciones de integridad referencial o dependencia de subconjunto.

Para que una restricción de integridad referencial tenga sentido, α debe ser igual a K1, o bien α y K1 deben ser conjuntos compatibles de atributos.

Modificación de la base de datos

La modificación de la base de datos puede ocasionar violaciones de la integridad referencial.

Insertar. Si se inserta una tupla t2 en r2, el sistema debe asegurar que hay una tupla t1 de r1 tal que t1[K] = t2[α]. Es decir,

t2[α] ∈ K (r1)

Borrar. Si se borra una tupla t1 de r1 el sistema debe calcular el conjunto de tuplas de r2 que hacen referencia a r1:

= t1[K] (r2)

Si este conjunto no es el conjunto vacío, o bien se rechaza la orden borrar como error, o bien se deben borrar las tuplas que hacen referencia a t1. La última solución puede llevar a borrados en cascada,dado que las tuplas pueden hacer referencia a tuplas que hagan referencia a t1, etcétera.

Actualizar. Hay que considerar dos casos: las actualizaciones de la relación que realiza la referencia (r2) y las actualizaciones de la relación a la que se hace referencia (r1).— Si se actualiza la tupla t2 de la relación r2 y esta actualización modifica valores de la clave externa α, se realiza una comprobación parecida a la del caso de la inserción. Si t′2 denota el nuevo valor de la tupla t2, el sistema debe asegurar que

t′2[α] ∈ K (r1)

— Si se actualiza la tupla t1 de la relación r1 y esta actualización modifica valores de la clave primaria (K), se realiza una comprobación parecida a la del caso del borrado. El sistema debe asegurar que = t1[K] (r2)

utilizando el valor anterior de t1 (el valor antes de que se lleve a cabo la actualización). Si este conjunto no es el conjunto vacío, la actualización se rechaza como error o se ejecuta en cascadade manera parecida al borrado.

Integridad referencial en SQLEjemplo del banco:create table cliente(nombre-cliente char(20),calle-cliente char(30),ciudad-cliente char(30),primary key (nombre-cliente));

create table sucursal(nombre-sucursal char(15),ciudad-sucursal char(30),activo integer,primary key (nombre-sucursal),check (activo > = 0));

create table cuenta(número-cuenta char(10),nombre-sucursal char(15),saldo integer,primary key (número-cuenta),foreign key (nombre-sucursal) references sucursal,check (saldo >= 0));

create table impositor(nombre-cliente char(20),número-cuenta char(10),primary key (nombre-cliente, número-cuenta),foreign key (nombre-cliente) references cliente,foreign key (número-cuenta) references cuenta);

Especificación de borrado y actualización en cascada:

create table cuenta(…foreign key (nombre-sucursal) references sucursalon delete cascadeon update cascade,…);

Actividad

Complétese la definición del LDD de SQL de la base de datos bancaria de la Figura anterior para incluir las relaciones préstamo y prestatario.

Considérese la siguiente base de datos relacional:

empleado (nombre-empleado, calle, ciudad) trabaja (nombre-empleado, nombre-empresa, sueldo) empresa (nombre-empresa, ciudad)jefe (nombre-empleado, nombre-jefe)

De una definición en el LDD de SQL de esta base de datos. Identifíquense las restricciones de integridad referencial que deban cumplirse e inclúyanse en la definición del LDD.

ASERTOS

Un aserto es un predicado que expresa una condiciónque se desea que la base de datos satisfaga siempre.

Las restricciones de dominio y las de integridad referencialson formas especiales de los asertos.

Ejemplos de estas restricciones pueden ser• La suma de todos los importes de los préstamos de cada sucursal debe ser menor que la suma de todos los saldos de las cuentas de esa sucursal.• Cada préstamo tiene al menos un cliente que tiene una cuenta con un saldo mínimo de 1.000 €.

create assertion restricción-suma check(not exists (select * from sucursal where (select sum(importe) from préstamo where préstamo.nombre-sucursal = sucursal.nombre-sucursal) >= (select sum (importe) from cuenta where préstamo.nombre-sucursal = sucursal.nombre-sucursal)));

create assertion restricción-saldo check(not exists (select * from préstamo where not exists (select * from prestatario, impositor, cuenta where préstamo.número-préstamo = prestatario.número-préstamo and prestatario.nombre-prestatario = impositor.nombre-cliente and impositor.número-cuenta = cuenta.número-cuenta and cuenta.saldo >= 1000)));

DISPARADORESUn disparador es una orden que el sistema ejecuta demanera automática como efecto secundario de la modificación de la base de datos.Para diseñar un mecanismo disparador hay que cumplir dos requisitos:1. Especificar las condiciones en las que se va a ejecutarel disparador. Esto se descompone en un evento que causa la comprobación del disparador y una condición que se debe cumplir para ejecutar el disparador.2. Especificar las acciones que se van a realizar cuando se ejecute el disparador. Este modelo de disparadores se denomina modelo evento-condición-acción.

Ejemplo

A modo de ejemplo supóngase que, en lugar de permitir saldos de cuenta negativos, el banco trata los descubiertos dejando a cero el saldo de las cuentas y creando un préstamo por el importe del descubierto. Este préstamo recibe un número de préstamo idéntico al número de cuenta que ha tenido el descubierto.Las acciones que hay que emprender son las siguientes:

• Insertar una nueva tupla s a la relación préstamo cons[nombre-sucursal] = t[nombre-sucursal]s[número-préstamo] = t[número-cuenta]s[importe] = – t[saldo]• Insertar una nueva tupla u a la relación prestatario con u[nombre-cliente] = «Santos»u[número-préstamo] = t[número-cuenta]• Hacer que t[saldo] sea 0.

Disparadores en SQLcreate trigger descubierto after update on cuentareferencing new row as nfilafor each row when nfila.saldo < 0 begin atomic insert into prestatario (select nombre-cliente, número-cuenta from impositor where nfila.número-cuenta = impositor.número-cuenta); insert into préstamo values (nfila.número-cuenta, nfila.nombre-sucursal, – nfila.saldo)update cuenta set saldo = 0 where cuenta.número-cuenta = nfila.número-cuenta end;

Versión MySQLcreate trigger descubierto before update on cuentafor each row begin if new.saldo<0 then insert into prestatario (select nombre_cliente, numero_cuenta from impositor where new.numero_cuenta = impositor.numero_cuenta); insert into prestamo values (new.numero_cuenta,new.nombre_sucursal,-new.saldo); set new.saldo = 0; end if;end;

Ejemplo

supóngase que se tienen las siguientes relaciones:• inventario(producto, nivel), que denota la cantidadactual (número/peso/volumen) del productoen el almacén.• nivelmínimo(producto, nivel), que denota la cantidadmínima a mantener de cada producto.• nuevopedido(producto, cantidad), que denota lacantidad de producto a pedir cuando su nivel caepor debajo del mínimo.• pedidos(producto, cantidad), que denota la cantidadde producto a pedir.

Se puede usar entonces el disparador mostrado para solicitar un nuevo pedido del producto.create trigger nuevopedido after update of cantidad on inventarioreferencing old row as ofila, new row as nfilafor each rowwhen nfila.nivel <= (select nivel from nivelmínimowhere nivelmínimo.producto = ofila.producto)and ofila.nivel >= (select nivel from nivelmínimowhere nivelmínimo.producto = ofila.producto)begin insert into pedidos (select producto, cantidad from nuevopedido where nuevopedido.producto= ofila.producto);end

Cuándo no deben usarselos disparadores

Para mantener los datos de resumen.Para las réplicas de las bases de datos.En el peor de los casos esto podría dar lugar a una cadena infinita de disparos.

Por ejemplo, supóngase que un disparador de inserción sobre una relación realice otra (nueva) inserción sobre la misma relación. La acción de inserción dispara otra acción de inserción, y así hasta el infinito.

Actividad

Escríbase un disparador SQL para realizar la siguiente acción:

Cuando se borre una cuenta, comprobar para cada tenedor de la cuenta si tiene otras cuentas y, si no, borrarlo de la relación impositor.

SEGURIDAD Y AUTORIZACIÓN

Los datos guardados en la base de datos deben estar protegidos contra los accesos no autorizados, de la destrucción o alteración malintencionadas además de la introducción accidental de inconsistencias que evitan lasrestricciones de integridad.

Entre las formas de acceso malintencionado se ncuentran:

• La lectura no autorizada de los datos (robo de información)• La modificación no autorizada de los datos• La destrucción no autorizada de los datos

Niveles de seguridad

Para proteger la base de datos hay que adoptar medidasde seguridad en varios niveles:

• Sistema de bases de datos.

• Sistema operativo.

• Red.

• Físico.

• Humano.

AutorizacionesLos usuarios pueden tener varios tipos de autorizaciónpara diferentes partes de la base de datos. Entre ellasestán las siguientes:

• La autorización de lectura permite la lectura de los datos, pero no su modificación.• La autorización de inserción permite la inserción de datos nuevos, pero no la modificación de los existentes.• La autorización de actualización permite la modificación de los datos, pero no su borrado.• La autorización de borrado permite el borrado de los datos.

Cont.

Además de estas formas de autorización para el accesoa los datos, los usuarios pueden recibir autorizaciónpara modificar el esquema de la base de datos:

• La autorización de índices permite la creación y borrado de índices.• La autorización de recursos permite la creación de relaciones nuevas.• La autorización de alteración permite el añadido o el borrado de atributos de las relaciones.• La autorización de eliminación permite el borrado de relaciones.

Autorizaciones y vistasUna vista puede ocultar los datos que un usuario no necesita ver.La capacidad de las vistas para ocultar datos sirve para simplificar el uso del sistema y para mejorar la seguridad.El uso del sistema se simplifica porque se permite al usuario restringir su atención a los datos de interés.Aunque puede que se niegue el acceso directo a una relación, puede que se le permita el acceso a parte de esa relación mediante una vista.Por tanto, se puede utilizar una combinación de seguridad en el nivel relacional y en el nivel de las vistas para limitar el acceso de un usuario precisamente a los datos que necesita.

Actividad

Utilizando las relaciones de la base de datos bancaria de ejemplo escríbase una expresión SQL para definir las vistas siguientes:a. Una vista que contenga los números de cuenta y los nombres de los clientes (pero no los saldos) de todas las cuentas de la sucursal de El Escorial.b. Una vista que contenga el nombre y la dirección de todos los clientes que tengan cuenta en el banco pero no tengan ningún préstamo.c. Una vista que contenga el nombre y el saldo medio de la cuenta de cada cliente de la sucursal de Collado Villalba.

Concesión de privilegiosEl usuario al que se le ha concedido alguna forma de autorización puede ser autorizado a transmitir esa autorización a otros usuarios. debe tener los mismos tipos de autorizaciones

Grafo de concesión de autorizaciones.

ABD

U1

U2

U3

U4

U5

PapelesEn la base de datos se crea un conjunto de papeles.

Las autorizaciones se conceden a los papeles, de igual modo que se conceden a usuarios individuales.

Se concede un conjunto de papeles a cada usuario de la base de datos (que puede ser vacío) para los que está autorizado.

En el ejemplo bancario, algunos ejemplos de papelesserían cajero, gestor-sucursal, auditor y administrador-del-sistema.

Trazas de auditoría

Una traza de auditoría es un registro histórico de todos los cambios (inserciones, borrados o actualizaciones) de la basede datos, junto con información sobre el usuario que realizó el cambio y en qué momento.

AUTORIZACIÓN EN SQLLa norma SQL incluye los privilegios delete, insert,select y update.

El lenguaje de definición de datos de SQL incluye órdenes para conceder y retirar privilegios.

La instrucción grant se utiliza para conferir autorizaciones. La forma básica de esta instrucción es la siguiente:

grant <lista de privilegios> on <nombre de relación ode lista> to <lista de usuarios/papeles>

Ej.: grant select on sucursal to U1, U2, U3

Cont.

El privilegio all privileges puede utilizarse como una forma abreviada de todos los privilegios que se puedenconceder.

De manera parecida, el nombre de usuario public hace referencia a todos los usuarios presentes y futuros del sistema.

SQL incluye también un privilegio usage que autoriza a un usuario a utilizar un dominio especificado (recuérdese que el dominio se corresponde con el concepto de tipo de un lenguaje de programación y puede ser definido por el usuario).

Papeles en SQL

Los papeles se pueden crear en SQL:1999 como siguecreate role cajero

Se pueden conceder privilegios a los papeles al igual que a los usuarios, como se ilustra en la siguiente instrucción

grant select on cuenta to cajeroLos papeles se pueden asignar a los usuarios, así como a otros papeles, como muestran estas instrucciones.

grant cajero to juancreate role gestorgrant cajero to gestorgrant gestor to maría

El privilegio de conceder privilegios

Un usuario o papel al que se le concede un privilegiono está autorizado de manera predeterminada a concedérselo a otros usuarios o papeles.Si se desea conceder un privilegio a un usuario y permitirle que lo transmita a otros usuarios hay que añadir la cláusula with grant option a la orden grant correspondiente.Por ejemplo, si se desea conceder a U1 el privilegio select sobre sucursal y que pueda transmitirlo a otros, hay que escribir

grant select on sucursal to U1 with grant option

Revocar privilegios

Para retirar una autorización se utiliza la instrucción revoke. Adopta una forma casi idéntica a la de grant: revoke <lista de privilegios> on <nombre de relación o de vista>from <lista de usuarios o papeles> [restrict | cascade]

Por tanto, para retirar los privilegios que se han concedidocon anterioridad hay que escribir

revoke select on sucursal from U1, U2, U3revoke update (importe) on préstamo from U1, U2, U3revoke references (nombre-sucursal) on sucursalfrom U1

Limitaciones de la autorización SQL

Las normas SQL actuales de autorización tienen algunasdeficiencias. Por ejemplo, supóngase que se desea que todos los estudiantes sean capaces de ver sus propiasnotas, pero no las del resto.

La autorización debe estar en el nivel de las tuplas, lo cual no es posible en los estándares de autorización de SQL.

DEPENDENCIAS FUNCIONALES

Una dependencia funcional es un tipo de restricción que constituye una generalización del concepto de clave

Conceptos básicosLas dependencias funcionales son restricciones del conjuntode relaciones legales. Permiten expresar hechos sobre la empresa que se modela con la base de datos.Sea R el esquema de una relación.El subconjunto K de R es una superclave de R si, en cualquier relación legal r(R), para todos los pares t1 y t2 de tuplas de r tales que t1 ≠ t2, t1 [K] ≠ t2 [K].Considérese el esquema de una relación R y sean α ⊆ R y β

⊆ R. La dependencia funcionalα →β

se cumple para el esquema R si, en cualquier relación legal r (R), para todos los pares de tuplas t1 y t2 de r tales que t1 [α] = t2 [α], también ocurre que t1 [β] = t2 [β].

Ejemplo

Considérese el esquemaEsquema-info-préstamo = (número-préstamo,

nombre-sucursal, nombre-cliente, importe)El conjunto de dependencias funcionales que se espera que se cumplan en este esquema de relación es

número-préstamo → importenúmero-préstamo → nombre-sucursal

Sin embargo, no se espera que se cumpla la dependencia funcional

Número-préstamo → nombre-clienteya que, en general, cada préstamo se puede conceder amás de un cliente

uso

Las dependencias funcionales se utilizarán de dosmaneras:1. Para probar las relaciones y ver si son legales según un conjunto dado de dependencias funcionales. Si una relación r es legal según el conjunto F de dependencias funcionales, se dice que r satisface F.2. Para especificar las restricciones del conjunto de relaciones legales. Así, sólo habrá que preocuparse por las relaciones que satisfagan un conjunto dado de dependencias funcionales. Si uno desea restringirse a las relaciones del esquema R que satisfagan el conjunto F de dependencias funcionales, se dice que F se cumple en R.

ejemplo

A B C D

a1 b1 c1 d1

a1 b2 c1 d2

a2 b2 c2 d2

a2 b3 c2 d3

a3 b3 c2 d4

se satisface A→C

C →A no se satisface

se satisface AB → D

Se dice que algunas dependencias funcionales sontriviales porque las satisfacen todas las relaciones.

Por ejemplo, A → A la satisfacen todas las relaciones que impliquen al atributo A.

En general, una dependencia funcional de la forma α →β es trivial si β α.⊆

Tablas del banconombre-cliente calle-cliente ciudad-cliente

Santos Mayor Peguerinos

Gómez Carretas Cerceda

López Mayor Peguerinos

Pérez Carretas Cerceda

Rupérez Ramblas León

Abril Preciados Valsaín

Valdivieso Goya Vigo

Fernández Jazmín León

González Arenal La Granja

Rodríguez Yeserías Cádiz

Amo Embajadores Arganzuela

Badorrey Delicias Valsaín

número-préstamo nombre-sucursal Importe

P-17 Centro 1000

P-23 Moralzarzal 2000

P-15 Navacerrada 1500

P-14 Centro 1500

P-93 Becerril 500

P-11 Collado Mediano 900

P-29 Navas de la Asunción 1200

P-16 Segovia 1300

P-18 Centro 2000

P-25 Navacerrada 2500

P-10 Galapagar 2200

nombre-sucursal ciudad-sucursal activo

Centro Arganzuela 9.000.000

Moralzarzal La Granja 2.100.000

Navacerrada Aluche 1.700.000

Becerril Aluche 400.000

Collado Mediano Aluche 8.000.000

Navas de la Asunción Alcalá de Henares 300.000

Segovia Cerceda 3.700.000

Galapagar Arganzuela 7.100.000

Ejemplos

Si se considera la relación cliente (en Esquemacliente) puede verse que se satisface

calle-cliente → ciudad-cliente.

En la relación préstamo (de Esquema-préstamo) se puede ver que se satisface la dependencia

número-préstamo → importe.

Se satisface nombre-sucursal → activo, igual queocurre con activo → nombre-sucursal

Diseñocuando se diseña una base de datos relacional, se enumeran en primer lugar las dependencias funcionales que se deben cumplir siempre. En el ejemplo del banco, en la lista de dependencias figuran:• En Esquema-sucursal:

nombre-sucursal → ciudad-sucursalnombre-sucursal → activo

• En Esquema-cliente:nombre-cliente → ciudad-clientenombre-cliente → calle-cliente

• En Esquema-préstamo:número-préstamo → importenúmero-préstamo → nombre-sucursal

• En Esquema-prestatario:Ninguna dependencia funcional

• En Esquema-cuenta:número-cuenta → nombre-sucursalnúmero-cuenta → saldo

• En Esquema-impositor:Ninguna dependencia funcional

Diseño de bases relacionales

Bases de datos

Descomposición

Ejemplo de descomposición

Sea el esquema:

esquema-empréstito = (nombre-sucursal, ciudad-sucursal, activo, nombre-cliente, número-préstamo, importe)

Al añadir una tupla se deben repetir algunos datos como la ciudad de la sucursal.

Si una sucursal se cambia de ciudad habrá que cambiar muchas tuplas.

La dependencia funcional nombre-sucursal ciudad-sucursal se espera que se cumpla , pero no nombre-sucursal número-préstamo.

No se puede representar directamente la información de una sucursal (nombre-sucursal, ciudad-sucursal, activo).

Peor aún, tendría que borrarse la información cuando se hayan pagado todos los prestamos.

tabla empréstito

nombre de la sucursal

ciudad de la sucursal activos

nombre-cliente

número-préstamo importe

Centro Arganzuela 1,800,000,000 Santos P-17 200,000

Moralzarzal La Granja 420,000,000 Gómez P-23 400,000

Navacerrada Aluche 340,000,000 López P-15 300,000

Centro Arganzuela 1,800,000,000 Sotoca P-14 300,000

Becerril Aluche 80,000,000 Santos P-93 100,000

Collado Mediano Aluche 1,600,000,000 Abril P-11 180,000

Navas de Asunción Alcalá de Henares 60,000,000 Valdivieso P-29 240,000

Segovia Cerceda 740,000,000 López P-16 260,000

Centro Arganzuela 1,800,000,000 González P-23 400,000

Galapagar Arganzuela 1,420,000,000 Rodríguez P-25 500,000

Cuenca Villaverde 15,000,000 Amo P-10 440,000

Supongamos que se separa en:

esquema-sucursal-cliente = (nombre-sucursal, ciudad-sucursal, activo, nombre-cliente)

esquema-préstamo-cliente = (nombre-cliente, número-préstamo, importe)

Se crean las tablas sucursal-cliente y préstamo-cliente por medio de

sucursal-cliente = Pnombre-sucursal, ciudad-sucursal, activo, nombre-cliente(empréstito)

préstamo-cliente = Pnombre-cliente , número-préstamo, importe(empréstito)

La reunión natural de estas tablas es

sucursal-cliente |><| préstamo-cliente

Esta reunión produce la tabla de la siguiente lámina

nombre de la sucursal

ciudad de la sucursal activos

nombre-cliente

número-préstamo importe

Centro Arganzuela 1,800,000,000 Santos P-17 200,000

Centro Arganzuela 1,800,000,000 Santos P-93 100,000

Moralzarzal La Granja 420,000,000 Gómez P-23 400,000

Navacerrada Aluche 340,000,000 López P-15 300,000

Navacerrada Aluche 340,000,000 López P-16 260,000

Centro Arganzuela 1,800,000,000 Sotoca P-14 300,000

Becerril Aluche 80,000,000 Santos P-17 100,000

Becerril Aluche 80,000,000 Santos P-93 100,000

Collado Mediano Aluche 1,600,000,000 Abril P-11 180,000

Navas de Asunción Alcalá de Henares 60,000,000 Valdivieso P-29 240,000

Segovia Cerceda 740,000,000 López P-15 300,000

Segovia Cerceda 740,000,000 López P-16 260,000

Centro Arganzuela 1,800,000,000 González P-23 400,000

Navacerrada Aluche 340,000,000 Rodríguez P-25 500,000

Galapagar Arganzuela 1,420,000,000 Amo P-10 440,000

El único camino para relacionar número-préstamo y nombre-sucursal es a través de nombre-cliente. Esto no es adecuado porque un cliente puede tener préstamos en varias sucursales.

Considere la siguiente descomposición:

Esquema-sucursal =(nombre-sucursal, ciudad-sucursal, activo)

Esquema-info-préstamo = (nombre-sucursal, nombre-cliente, número-préstamo, importe)

Se mantiene la dependencia funcional

nombre-sucursal activo ciudad-sucursal

pero nombre-cliente no determina funcionalmente a número-préstamo

DefiniciónSea C un conjunto de ligaduras en la base de datos. Una descomposición [R1, R2, ..., Rn] de un esquema de relación R es una descomposición de reunión sin pérdida para R si para todas las relaciones r que son legales bajo C

r = R1(r) |><| R2(r) |><| |><| Rn(r)

Primera forma normalLos dominios deben de ser atómicos

Ejemplos de dominios no atómicosconjunto de nombres, atributos compuestosNúmero de identificación como CS101 quepueden dividirse en partes

un esquema de relación R esta en primera forma normal si losdominios de todos los atributos son atómicos

Los valores no-atómicos complican el almacenamiento y producen almacenamiento redundante (repetido) de los datos

Ejemplo:. conjunto de cuentas guardado con cada cliente, y conjunto de propietarios guardado con cada cuenta

Suponemos todas las relaciones están en primera forma normal

Primera forma normal (cont.)

La atomicidad es realmente una propiedad de como los elementos de un dominio son usados.

Ejemplo: Las cadenas se consideran normalmente indivisibles

Suponga que a los estudiantes se les da un número el cual es una cadena de la forma CS0012 o EE1127

Si los dos primeros caracteres son extraídos para encontrar el departamento, el dominio de los números no es atómico.

Hacer esto es una mala idea: lleva a codificar información en el programa de aplicación en lugar de en la base de datos.

Objetivo - inventar una teoría para lo siguiente

Decida si una relación particular R esta en "buena" forma.

En el caso de que una relación R no este en "buena" forma, descomponerla en un conjunto de relaciones {R1, R2, ..., Rn} tales que:

cada relación este en "buena" formala descomposición sea sin reunión con pérdida

Nuestra teoría esta basada en:

dependencias funcionalesdependencias multivaluadas

Ligaduras de los dominios

La ligadura de dominio permite la verificación de valores al momento de agregar datos a la base de datos. Solo aquellos que cumplan con la ligadura serán aceptados como datos válidos, los demás serán rechazados.

En SQL se utiliza la sentencia check para establecer la ligadura de dominios, ejemplos:create domain sueldo-por-hora numeric(7,1)

constraint comprobacion-valor-sueldocheck (value >= 800)

create domain numero-cuenta char(10)constraint comprobacion-numero-cuenta-nulo

check (value not null)

Integridad referencial

Sean r1(R1) y r2(R2) dos relaciones con claves primarias K1 y K2. Se dice que un subconjunto de R es una clave externa que hace referencia a K1 de la relación r1 si se exige que para cada t2 de r2 haya una tupla t1 en r1 tal que t1[K1] = t2[]

Las exigencias de este tipo se denominan ligaduras de integridad referencial o dependencias de subconjunto.

La última denominación proviene de que lo anterior puede expresarse como:

(r2) K1 (r2)

Modificación de la base de datosinsertar. Si se inserta una tupla t2 en r2, el sistema debe asegurar que hay una tupla t1 en r1 tal que t1[K] = t2[], es decir

t2[] K1 (r2)

borrar. Si se borra una tupla t1 en r1, el sistema debe calcular el conjunto de tuplas de r2 que hacen referencia a r1:

= t1[K] (r2)

Actualizar: Hay que considerara dos casos: las actualizaciones de la relación que realiza la referencia (r2) y las actualizaciones de la relación a la que se hace referencia (r1).

- si se actualiza la tupla t2 de la relación r2 y esta actualización modifica los valores de la clave externa , se realiza una comprobación parecida al caso de la inserción. El sistema debe asegurar que

t2’[] K (r1)

- si se actualiza la tupla t1 de la relación r1 y esta actualización modifica los valores de la clave externa primaria (K), se realiza una comprobación parecida al caso del borrado. El sistema debe asegurar que

= t1[K] (r2)

Dependencias funcionalesSea R un esquema de relación. Sean R y R. La dependencia fucnional , se cumple en R si en cualquier relación legal r(R), para todos las pares de tuplas t1 y t2 de r tales que t1[] = t2[] también ocurre t1[] = t2[].

Considere el esquema

esquema-información-préstamo =

(nombre-sucursal, número-préstamo, nombre-cliente, importe)

Se esperan las siguientes dependencias funcionales

número-préstamo importe

número-préstamo nombre-sucursal

pero no

número-préstamo nombre-cliente

Utilización1. para especificar las ligaduras del conjunto de relaciones legales. Así solo habrá que preocuparse por las relaciones que satisfagan un conjunto dado de dependencias funcionales.

2. Para examinar las relaciones y comprobar si son legales bajo un conjunto dado de dependencias funcionales.

A B C D

a1 b1 c1 d1

a1 b2 c1 d2

a2 b2 c2 d2

a2 b3 c2 d3

a3 b3 c2 d4

Se satisface A C

No se satisface C A

Se satisface AB D

Ejemplo bancarioEsquema esquema-sucursal

nombre-sucursal ciudad-sucursal

nombre-sucursal activo

Esquema esquema-cliente

nombre-cliente ciudad-cliente

nombre-cliente calle-cliente

Esquema esquema-prestamo

número-préstamo importe

número-préstamo nombre-sucursal

Esquema esquema-prestatario No hay

Esquema esquema-cuenta

número-préstamo nombre-sucursal

número-préstamo saldo

Esquema esquema-impositor No hay

Cierre de un conjunto de dependencias funcionales

Sea un esquema de relación R = (A, B, C, G, H, I) y el conjunto de dependencias funcionales

A BA CCG HCG IB H

A H está implicada lógicamente.

El cierre de un conjunto de dependencias funcionales F es el conjunto de todas las dependencias funcionales implicadas lógicamente por F. Se denota por F+.

Por las reglas que siguen CG HI y AG I

Reglas de inferenciaRegla de reflexividad. Si es un conjunto de atributos y , entonces se cumple que .

Regla de aumentatividad. Si se cumple que y es un conjunto de atributos, entonces se cumple que .

Regla de transitividad. Si se cumple que y , entonces

Estas reglas se conocen como axiomas de Armstrong. Se agregan las siguientes reglas deducibles a partir de las anteriores.

Regla de la unión. Si se cumple que y , entonces se cumple

Regla de la descomposición. Si se cumple que , entonces se cumple que y que

Regla de la seudotransitividad. Si se cumple que y que , entonces se cumple

Cierre de los conjuntos de atributos

Para comprobar si un conjunto es una superclave hay que preparar un algoritmo para calcular el conjunto de los atributos determinados funcionalmente por .

Se denomina cierre de sobre F al conjunto de todos los atributos determinados funcionalmente por bajo un conjunto de dependencias funcionales F; se denota por +.

Algoritmo en pseudo Pascal

resultado : = ;while (cambios en resultado) do for each dependencia funcional in F do begin if resultado then resultado := resultado ; end

EjemploPara el esquema de relación R = (A, B, C, G, H, I) y el conjunto de dependencias funcionales

A BA CCG HCG IB H

Aplicamos el algoritmo para calcular (AG)+:

paso dependencia resultado

1 A B ABG2 A C ABCG 3 CG H ABCGH 4 CG I ABCGHI

¿Es AG una llave candidata?

Recubrimiento canónicoConjuntos de dependencias funcionales pueden ser inferidos a partir de otros

Por ejemplo: A C es redundante en {A b, B C}partes de una dependencia funcional puede ser redundante

o sea: en RHS: {A B, B C, A CD} se puede simplificar a {A B, B C, A D}

o sea: en LHS: {A B, B C, AC D} se puede simplificar a {A B, B C, A D}

Intuitivamente, un recubrimiento canónico de F es un conjunto "mínimo" de dependencias funcionales equivalente a F, sin teniendo dependencias redundantes o partes redundantes de dependencias.

Atributos extrañosConsidere un conjunto F de dependencias funcionales y la dependencia funcional en F.

El atributo A es extraño en si A de y F implica lógicamente (F-{ }{(-A) }

El atributo A es extraño en si A y el conjunto de dependencias funcionales (F-{ } { (A-)} implica lóigicalmente a F

Note: la implicación en la dirección contraria es trivial en cada uno de los casos de arriba, ya que una dependencia funcional "fuerte" siempre implica a una más débil

Ejemplo: dado f = {A C. AB C}B es extraña en AB C debido a {A C, AB >C} implica

lógicamente A C (el resultado de quitar B de AB C)

Ejemplo: dado f = {A C.AB CD}C es extraña en AB CD debido a AB C es inferido aun despues

de borrar C

Prueba si un atributo es extraño

Considere un conjunto F de dependencias funcionales y la dependencia funcional en F

Para probar si A es extraño en a calcule ([] - A)+ usando las dependencias funcionales en F, cheque si ([] - A)+ contiene , si es así, A es extraño en .

Para probar si el atributo A elemento de es extraño en calcule + usando solo dependencias funcionales en F‘ = (F-{}) {(b-A)}, cheque si + contine a A, si es así, A es extraño en .

Recubrimiento canónicoUn Recubrimiento canónico para F es un conjunto de dependencias funcionales Fc tales que:

F implica lógicamente todas las dependencias en Fc yFc implica lógicamente todas las dependencias en F yNinguna dependencia funcional en Fc contiene atributos extraños yTodos los lados izquierdos de dependencias funcionales en Fc son únicos

Para calcular el recubrimiento canónico para Frepeat Use la regla de unión para reemplazar cualquier dependencia en F 1 y 1 2 con1 2 encuentre una dependencia funcional con un atributo extraño en o en if se halla el atributo extraño, elimínelo de until que F no cambieNote que la regla de unión puede ser aplicable después de que los atributos extraños han sido borrados, por esto deberá ser reaplicada.

aplicaciónR = (A, B, C)F = {A BC

B C A BAB C}

Combine A BC and A B into A BCEl conjunto es ahora {A BC, B C, AB C}

A is extraño en AB CCheque si el resultado de borrar A de AB C es implicado por las otras dependencias

Si: en efecto, B C está aún presente!El conjunto es ahora {A BC, B C}

C is extraño en A BC Cheque si A C esta lógicamente implicado por A B y las otras dependencias

Si: usando transitividad en A B and B C. Se puede usar cerradura de atributos de A en casos más complejos.

El recubrimiento canónico es: A BB C

Forma normal de Boyce-Codd

Un esquema de relación R esta en FNBC con respecto a un conjunto de dependencias funcionales si todas las dependencias funcionales en F+ de la forma

donde R y R, por lo menos una de las siguientes se cumple: es trivial (o sea ) es superllave de R

Ejemplo de un esquema no en FNBC:prestatario_préstamo = (cliente_id, número_préstamo, cantidad)

debido a que numero_prestamo cantidad en prestatario_prestamo se cumple pero numero_prestamo no es superclave

EjemploSean los siguientes esquemas y dependencias funcionales

Esquema esquema-cliente = (nombre-cliente , calle-cliente, ciudad-cliente)

nombre-cliente ciudad-cliente calle-cliente

Esquema esquema-sucursal = (nombre-sucursal, activo, ciudad-sucursal)

nombre-sucursal activo ciudad-sucursal

Esquema esquema-info-préstamo = (nombre-sucursal, nombre-cliente, número-préstamo, importe)

número-préstamo importe nombre-sucursal

Podemos afirmar que esquema-cliente está en FNBC, también esquema-sucursal está en FNBC.

Pero esquema-info-préstamo no está en FNBC ya que número-préstamo no es superllave de esquema-info-préstamo.

Descomposición de un esquema en BCNF

Suponga que tenemos un esquema R y una dependencia no trivial causa una violación de FNBC

Descomponemos R en:( )(R--))

En nuestro ejemplo = numero_prestamo = cantidad

y prestatario_prestamo se reemplaza por( ) = (numero_prestamo,cantidad)(R-(-)) = (cliente_id, numero_prestamo)

Algoritmo de descomposición

resultado := {R};hecho := false;calcular F’;while (not hecho) do if(hay un esquema Ri de resultado que no este en FNBC) then begin sea a ->b una dependencia funcional no trivial que se cumpla en Ri de modo que a -> Ri, no está en F’ y que ainter b = fi; resultado := (resultado – Ri) union (Ri – b)(a,b) endelse hecho := true;

Donde F’ es la unión de las dependencias funcionales en donde solo aparecen atributos de un esquema en particular.

EjemploConsidere el esquema

esquema-empréstito = (nombre-sucursal, ciudad-sucursal, activo, nombre-cliente, número-préstamo, importe)

Con las siguientes dependencias funcionales

nombre-sucursal activo ciudad-sucursal

número-préstamo importe nombre-sucursal

una clave candidata es (número-préstamo, nombre-cliente)

La aplicación del algoritmo da:

1. ya que nombre-sucursal no es una superclave, el esquema se debe se reemplaza por

esquema-sucursal = (nombre-sucursal, ciudad-sucursal, activo)

esquema-info-préstamo = (nombre-sucursal, nombre-cliente, número-préstamo, importe)

2. en este esquema es clave de y por lo tanto está en FNBC

Ejemplo (cont.)3. número-préstamo no es clave en esquema-info-préstamo , por lo que hay que reemplazarlo con

esquema-préstamo = (nombre-sucursal, número-préstamo, importe)

esquema-prestatario = (nombre-cliente, número-préstamo)

Estos esquemas están en FNBC

BCNF y conservación de las dependencias

Ligaduras, incluyendo las dependencias funcionales, son costosas para verificar en la práctica a que pertenezcan a una sola relación

Si es suficiente probar solo aquellas dependencias en cada relación individual de la descomposición de manera de asegurar que todas lasdependencias funcionales se cumplan, entonces esa descomposición conserva las dependencias.

Debido a que no siempre es posible obtener ambas FNBC y conservación de las dependencias, la consideramos una forma normal débil, conocida como tercera forma normal.

Tercera forma normalUn esquema de relación R esta en tercera forma normal (3NF) si para todas:

en F+

por lo menos una de las siguientes se cumple:

es trivial (o sea ) es superllave para RCada atributo A en - esta contenido en una llave candidata para R. (note: cada atributo puede ser en una llave candidata diferente)

Si una relación esta en FNBC esta en 3NF (ya que en FNBC una de las primeras dos condiciones de arriba se debe cumplir)

La tercera condición es una relajación mínima de FNBC para asegurar la conservación de dependencias.

Algoritmo 3NF que preserva dependencias

Sea Fc un recubrimiento canónico de F;

i := 0;for each dependencia funcional en Fc do

if ninguno de los esquemas Rj, 1 j i contiene then begin

i := i + 1;Ri :=

endif de los esquemas Rj, 1 j i contiene un clave candidata para R

then begini := i + 1;Ri := cualquier clave candidata para R;

end return (R1, R2, ..., Ri)

Algoritmo 3NF que preserva dependencias (cont.)

El algoritmo asegura que:

Cada esquema de relación Ri esta en 3FN

La descomposición preserva dependencias y reunión sin pérdida

EjemploEsquema de relation:

cliente_banquero_sucursal = (cliente_id, empleado_id, nombre_sucucral, tipo )

Las dependencias funcionales de este esquema son:

cliente_id, empleado_id nombre_sucucral tipoempleado_id nombre_sucucral cliente_id, nombre_sucucral empleado_id

Calculamos el recubrimiento canónico

nombre_sucucral es extraño en el r.h.s. de la 1st dependenciaNuingún otror atributo es extraño, por tanto obtenemos FC = cliente_id, empleado_id tipo

empleado_id nombre_sucucral cliente_id, nombre_sucucral empleado_id

ejemplo (cont.)El lazo for genera el siguiente esquema 3NF:

(cliente_id, empleado_id, tipo ) (empleado_id, nombre_sucursal) (cliente_id, nombre_sucursal, empleado_id)

Observe que (cliente_id, empleado_id, tipo ) contiene una clave candidata del esquema original, por tanto es necesario agregar más equemas de relación.

Si la FDs fuera considerada en order different, con la 2nda considerada después de la tercera,

(empleado_id, nombre_sucursal) no sería incluida en la descomposición debido a que es un subconjunto de (cliente_id, nombre_sucursal, empleado_id)Extensiones Menores del algoritmo de decomposicion 3NF: al final del lazo for, detectar y borrar esquemas, tales que (empleado_id, nombre_sucursal), los cuales son subconjuntos de otros esquemas resultantes no dependen en el orden en que FDs son considerados.El esquema resultado simplificado 3NFes: (cliente_id, empleado_id, tipo) (cliente_id, nombre_sucursal, empleado_id)

Objetivos de Normalización

Sea R un esquema de relación con un conjunto F de dependencias funcionales.

Decida si un esquema de relación R esta en "buena" forma.

En el caso de que el esquema de relación R no este en "buena" forma, descompóngalo en un conjunto de esquemas de relación {R1, R2, ...,Rn} tales que:

cada esquema de relación este en buena formala descomposición es una descomposición sin pérdidaPreferiblemente, la descomposición debe ser tal que conserve las dependencias.

¿Que tan buena es NFBC?

Hay esquemas de bases de datos en NFBC que no parecen suficientemente normalizadosConsidere la base de datos

clases(curso, maetro, libro)

tal que (c, m, b) elemento de clases significa que m es calificado para enseñar c, y b es el libro de texto para c.

La base de datos se supone que lista para cada curso un conjunto de maestros cualquiera de ellos puede ser el instructor, y un conjunto de libros, todos los cuales son requeridos para el curso (sin importar quien lo enseña)

¿Que tan buena es NFBC? (cont.)curso maestro librobase de datos Avi DB conceptsbase de datos Avi Ullmanbase de datos Hank DB conceptsbase de datos Hank Ullmanbase de datos Sudarsha DB conceptsbase de datos Sudarsha UllmanSistemas oper. Avi OS conceptsSistemas oper. Avi StallingsSistemas oper. Pete OS conceptsSistemas oper. Pete Stallings

No hay dependencias funcionales no-triviales y por lo tanto la relación está en BCNF

Anomalias de inserción - o sea si Marilyn es una nueva maestra que puede enseñar dases de datos, se deben insertar dos tuplas

(bases de datos, Marilyn, DB concepts)(bases de datos, Marilyn, Ullman)

¿Que tan buena es NFBC? (cont.)

Por lo tanto es mejor descomponer clases en:

curso maestrobase de datos Avibase de datos Hankbase de datos SudarshanSistemas oper. AviSistemas oper. Jim

Maestros

curso librobase de datos DB conceptsbase de datos UllmanSistemas oper. OS conceptsSistemas oper. Shaw

libro