BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

UNIDAD 5: ADMINISTRACION DE BASES DE DATOS

Tema 1: Arquitectura ClienteServidor en Bases de Datos
Combinan las fortalezas del enfoque tradicional (mainframe terminales tontos) con la
arquitectura LAN basada en PCs: cliente inteligente servidor inteligente. Presenta las
siguientes ventajas:
-

Hacen la data ms accesible

Reducir costos de hardware
Soportar interfaces grficas de usuario (GUI)
Construcciones basadas en tecnologas abiertas y no propietarias

Cliente

Servidor
DBMS

Aplicacin
Base de
Datos

Figura 6.1. Arquitectura Cliente-Servidor en Bases de Datos

Capas de una aplicacin Cliente-Servidor

Una aplicacin cliente-servidor convencional presenta tres capas:
-

Presentacin: Relacionada con la interfaz grfica de usuario (GUI) con la que el

usuario interacta para realizar peticiones, visualizar consultas, ingresar datos y
configurar los parmetros de la aplicacin.
Lgica: Relacionada directamente con la lgica de la aplicacin. Son los programas
que realizan el procesamiento de la informacin.
Datos: Relacionada con la base de datos, donde se almacena la informacin
persistente del sistema.

Arquitecturas Cliente-Servidor
Dependiendo de la forma en que se organicen y ubiquen las tres capas de una aplicacin
cliente-servidor, la arquitectura toma dos formas comunes: la arquitectura de 2 niveles
(tradicional) y la de 3 niveles (ms reciente).
Arquitectura de dos niveles
En una arquitectura cliente-servidor de dos niveles el cliente (front-end) ejecuta las
capas de presentacin y lgica de la aplicacin de software, que obtiene su data
desde un servidor de base de datos (back-end). El servidor basado en el DBMS
centraliza el control sobre la data y desempea mucho del procesamiento relacionado
con la data, dejando al cliente la responsabilidad de correr las aplicaciones.
Un problema comn de la arquitectura de dos niveles es que el cliente debe ser
configurado para incluir un driver para cada tipo de base de datos accesada. Esto
puede ser costoso, ya que este tipo de drivers generalmente necesitan licencia. Ms
an, en esta arquitectura suelen surgir problemas de configuracin y mantenimiento
de software. Los drivers de varios productos pueden ser mutuamente incompatibles

Facultad de Ingeniera

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

y requieren de un considerable trabajo para mantener a los clientes actualizados con

la ltima versin de cada driver.
La figura 6.2 muestra el esquema de una arquitectura cliente servidor de dos niveles.

Cliente

Servidor

Aplicacin
(presentacin + lgica)

DBMS1

DBMS2

Base de
Datos

Base de
Datos

Driver Manager

Driver
DBMS1

Driver
DBMS2

Figura 6.2. Arquitectura Cliente-Servidor de dos niveles

Arquitectura de tres niveles
En una arquitectura cliente-servidor de tres niveles se separa la presentacin de la
lgica de la aplicacin. Con esto se intenta reducir las desventajas de la arquitectura
de dos niveles. En esta arquitectura, las capa de presentacin no se comunica
directamente con un DBMS.
En lugar de esto, un componente intermedio
(middleware) se interpone entre la presentacin y la base de datos. Con esto se
mejora la seguridad de la informacin y el mantenimiento de la aplicacin.
El middleware simplifica la configuracin de clientes, los cuales no necesitarn un
driver distinto para cada tipo de DBMS accesado. En lugar de eso, los clientes slo
necesitan comunicarse con el middleware. La componente middleware comnmente
provee de facilidades de cach para acelerar el acceso a la data y reducir el trfico en
la red. Mejorar el desempeo de la red es particularmente importante ahora que el
Internet ha reemplazado a las LAN de alta velocidad, en la interconexin de clientes
y servidores.
Las ventajas de una arquitectura de tres niveles se pueden resumir en: seguridad,
escalabilidad y simplificacin en la administracin del cliente.
La figura 6.3 muestra el esquema de una arquitectura cliente-servidor de tres
niveles.

Cliente

Middleware

Aplicacin
(presentacin)

Aplicacin
(lgica)

Servidor
DBMS1

DBMS2

Base de
Datos

Base de
Datos

Driver Manager

Driver
DBMS1

Driver
DBMS2

Figura 6.3. Arquitectura Cliente-Servidor de tres niveles

Facultad de Ingeniera

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

Comunicacin con un Servidor de Bases de Datos

Para que una aplicacin establezca comunicacin con un servidor de bases de datos debe
poseer el driver del DBMS que se quiere accesar. Este driver es provedo por el fabricante al
momento de licenciar el DBMS y debe ser configurado en el cliente. Existe un driver por cada
DBMS (como se muestra en las figuras 6.2 y 6.3).
Parmetros de comunicacin entre cliente y servidor de bases de datos
Una vez establecida la comunicacin entre la aplicacin cliente y el servidor de bases de
datos, la interaccin queda establecida a travs de comandos SQL.
SQL fue originalmente diseado para uso interactivo. La idea fue que un usuario podra
ingresar por el teclado los comandos SQL especificando la data que buscaba. El intrprete
respondera por pantalla o impresora la data solicitada. Pero los programadores quisieron
usar el SQL dentro de sus programas, sin teclado. Ellos queran una manera de simplificar
las partes de sus programas que accesaban la data almacenada en la base de datos. SQL
fue inicialmente pensado sin proveer esta ayuda.
Para direccionar esta necesidad, SQL fue extendido de varias maneras. De hecho, el SQL
embebido, extiende los lenguajes de programacin al incluir nuevas construcciones que
especifican operaciones SQL, tales como recuperar y modificar registros.
Un segundo enfoque fue proveer SQL a travs de los drivers ODBC y JDBC. JDBC provee un
API para que los programadores puedan accesar bases de datos SQL. JDBC est basado en
SQL-92.
El diseo de JDBC est basado en ODBC (Open Database Connectivity), una forma estndar
de accesar bases de datos compatibles con SQL que fue originalmente implementado por
Microsoft. ODBC simplemente provee un mtodo de conectar una aplicacin a una fuente de
datos. Muchos productores han adaptado sus bases de datos para ODBC. Incluso JDK 1.1.
incluye un puente que permite acceso JDBC a cualquier base de datos compatible con ODBC.
As, los drivers estn clasificados segn el cliente que los configure:
-

Para aplicaciones Java se utiliza JDBC.

Para aplicaciones distintas a Java se utiliza ODBC.
Existen drivers JDBC/ODBC utilizado para comunicar aplicaciones Java con
DBMSs que slo poseen drivers ODBC.

La figura 6.4 muestra la arquitectura general de los APIs JDBC (funciona de manera similar
al ODBC) y JDBC/ODBC.
Los parmetros para establecer una conexin entre la aplicacin cliente y el servidor de
bases de datos son:
-

Host: Direccin IP o dominio donde se encuentra ubicado el servidor de bases de

datos.
Base de Datos: nombre de la base de datos a la que se desea conectar.
Usuario: Nombre de la cuenta del usuario de la base de datos con privilegios para
accesar a la informacin.
Contrasea: Clave secreta del usuario con provilegios para accesar a la
informacin de la base de datos.
Consulta: sentencia SQL que permite realizar algn tipo de accin (consulta o
manipulacin de los datos) en la base de datos.

Facultad de Ingeniera

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

Conexiones con JDBC/ODBC

Conexiones con JDBC

Aplicaciones Java

Aplicaciones Java

JDBC API

JDBC API

JDBC Driver Manager

JDBC Driver Manager

JDBC/ODBC Brigde
JDBC
Driver
Protocolo
Sybase

JDBC
Driver
ODBC Driver Manager

Protocolo
Oracle

...

ODBC
Driver

DBMS
Oracle

DBMS
Sybase

Protocolo
Sybase

ODBC
Driver

...

DBMS
Sybase

Protocolo
Oracle
DBMS
Oracle

Figura 6.4. Arquitectura de JDBC y JDBC/ODBC

Facultad de Ingeniera

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

Tema 2: Administracin de Bases de Datos

2.1. Transacciones
Estamos interesados principalmente en DBMS del tipo multiusuario. En este escenario, la
informacin almacenada en la BD puede ser accesada en forma concurrente por los
programas de los distintos usuarios ya sea para extraer datos o modificarlos.
Sin un mecanismo de control de concurrencia puede llegarse a un estado inconsistente de la
BD.
Para ilustrar algunos de los problemas que se presentan al no tener un sistema de control de
concurrencia usaremos dos transacciones muy simples:
T1

T2

Read(X)
X:=X-N
Write(X)
Read(Y)
Y:=Y+N
Write(Y)

Read(X)
X:=X+M
Write(X)

Actualizacin perdida (lost update)

Supongamos que las operaciones de T1 y T2 se entremezclan en el siguiente orden:
T1

T2

Read(X)
X:=X-N
Read(X)
X:=X+M
Write(X)
Read(Y)
Write(X)

Esta actualizacin se pierde

Y:=Y+N
Write(Y)
Por ejemplo, T1 puede estar cancelando N reservas en un vuelo y agregndolas de
nuevo al vuelo como disponibles, en tanto que T2 simplemente reserva M asientos en el
mismo vuelo que T1 cancela. Esperamos que el nmero de asientos disponibles en el
primer vuelo sea el original N + M.
En la prctica el nmero slo ser el original + M porque la primera actualizacin se
pierde.
Lectura sucia (dirty read)
Una transaccin actualiza un dato y luego sta falla.
actualizado antes de ser devuelto a su valor original.
T1

Otra transaccin lee el valor

T2

Read(X)
X:=X-N
Write(X)
Read(X)
X:=X+M
Write(X)

T2 lee un valor temporal de X

Read(Y)
FALLA!!!!

Facultad de Ingeniera

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

El concepto de Transaccin
Unidad de trabajo atmica, indivisible que se ejecuta en trminos de todo o nada.
Cuando una transaccin se entrega al DBMS para su ejecucin, el sistema es responsable de
que:
a) Todas las operaciones de la transaccin se completen y el resultado se refleje
permanentemente en la BD, o bien
b) No hay ningn efecto de la transaccin en la BD
No se acepta ejecucin de una parte de la transaccin, situacin que puede producirse en
caso de fallas (fsicas, sistema, programa, control de concurrencia, etc.)
Trabaja con el sistema de recuperacin (recovery), que tpicamente debe llevar un control de
las siguientes operaciones:

Begin_transaction
Read y Write
End_transaction
Commit_transaction
Rollback (abort)
Undo
Redo

Read, Write

Begin_
Transaction

Commit

Activo

Abort

Comprometido

Parcialmente
Comprometido

End_
Transaction

Abort

Fall

Terminado
End_
Transaction

Ejemplo de una transaccin:

BEGIN TRANSACTION
{
INSERT INTO Pieza_Proveedor VALUES ( A567, 291029193, 1000 );
IF (ocurre algn error) THEN
ROLLBACK;
RETURN;
ENDIF
UPDATE Pieza SET Stock = Stock + 1000 WHERE CodPieza = A567;
IF (ocurre algn error) THEN
ROLLBACK;
RETURN;
ENDIF
COMMIT;
RETURN;
}
END TRANSACTION

Facultad de Ingeniera

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

El punto a destacar en el ejemplo es que lo que supone ser una sola operacin atmica
aadir una nueva compra, implica de hecho dos actualizaciones a la base de datos: una
operacin INSERT y una operacin UPDATE. Lo que es ms, la base de datos ni siquiera es
constante entre esas dos actualizaciones, ya que viola temporalmente la restriccin que
indica que el valor de Stock para la parte A567 debe ser igual a la suma de todos los valores
Cantidad para esa pieza. Por lo tanto, una unidad de trabajo lgica (por ejemplo, una
transaccin) no es necesariamente una sola operacin a la base de datos, sino que en
general es una secuencia de varias de estas operaciones que transforman un estado
consistente de la base de datos en otro estado consistente sin que sea necesario conservar la
consistencia en todos los puntos intermedios.
El componente del sistema que proporciona esta atomicidad es conocido como administrador
de transacciones y las operaciones COMMIT y ROLLBACK son la clave de cmo funciona:
o

La operacin COMMIT indica la finalizacin de una transaccin satisfactoria: indica al

administrador de transacciones que una unidad de trabajo lgica ha concluido
satisfactoriamente, que la base de datos est o debera estar nuevamente en un
estado consistente y que todas las actualizaciones efectuadas por esa unidad de
trabajo ahora pueden ser confirmadas o definitivas.

Por el contrario, la operacin ROLLBACK indica la finalizacin de una transaccin no

satisfactoria: indica al administrador de transacciones que algo ha salido mal, que la
base de datos puede estar en un estado inconsistente y que todas las actualizaciones
realizadas hasta este momento por la unidad de trabajo lgica deben ser revertidas o
deshechas.

Propiedades ACID de las Transacciones

Atomicidad
Las transacciones son atmicas (todo o nada).
Consistencia
Las transacciones conservan la consistencia de la base de datos. Es decir, una transaccin
transforma un estado consistente de la base de datos en otro igual, sin necesidad de
conservar la consistencia en todos los puntos intermedios.
Aislamiento
Las transacciones estn aisladas entre s. Es decir, aunque en general hay muchas
transacciones ejecutndose en forma concurrente, las actualizaciones de una transaccin
estn ocultas ante las dems, hasta que esa transaccin sea confirmada. Otra forma de decir
lo mismo es que para dos transacciones distintas como T1 y T2, T1 podr ver las
actualizaciones de T2 (despus de que T2 haya sido confirmada) o T2 podr ver las de T1
(despus de que T1 haya sido confirmada), pero no podrn suceder ambas cosas.
Durabilidad
Una vez que una transaccin es confirmada, sus actualizaciones sobreviven en la base de
datos aun cuando haya una cada posterior del sistema.

Facultad de Ingeniera

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

2.2. Control de Concurrencia

En un escenario de ejecucin concurrente de transacciones se exige la propiedad de
seriabilidad.

T1

T3

BD

T4

T2
Se considera que una ejecucin de un conjunto dado de transacciones es correcta cuando es
serializable; es decir, cuando produce el mismo resultado que una ejecucin serializable de
las mismas transacciones, ejecutando una a la vez. Esto se justifica por:
o Las transacciones individuales son tomadas como correctas; es decir, se da por
hecho que transforman un estado correcto de la base de datos en otro estado
correcto.
o Por lo tanto, tambin es correcta la ejecucin de una transaccin a la vez en
cualquier orden serial, y se dice cualquier orden serial debido a que las
transacciones individuales son consideradas independientes entre s.
o Por lo tanto, una ejecucin intercalada es correcta cuando equivale a alguna
ejecucin serial, es decir, cuando es serializable.

T2
T1
T4
T3

Soporte de Transacciones Atmicas = Control de Concurrencia + Subsistema de Recuperacin

El control de concurrencia bsicamente maneja dos enfoques

a.

Optimista (time-stamps)
El enfoque o filosofa optimista est basada en la suposicin que los conflictos entre
usuarios que accesan simultneamente un datos son escasos, entonces la idea es
dejarlos trabajar tranquilos y solamente validar al final.

b.

Pesimista (locks)
El enfoque o filosofa pesimista asume que lo ms probable es que existirn conflictos,
entonces impidamos desde un principio las situaciones de conflicto mediante un
mecanismo de cerrojos (locks).

Facultad de Ingeniera

BD Bases de Datos

a.

Unidad 5: Administracin de Bases de Datos

Control de Concurrencia Pesimista

Cundo usar el Control de Concurrencia Pesimista
Utilizado para probabilidad de conflictos alta:
o
o
o

BD pequea, muchos usuarios

Mucha actualizacin
Transacciones muy grandes

Locks o Bloqueos
Cuando una transaccin deba asegurarse de que algn objeto en el que est interesada
por lo general una tupla de la base de datos no cambiar de ninguna forma mientras
lo est usando, adquiere un lock o bloqueo sobre ese objeto. El efecto del bloqueo es
inhibir todas las dems transacciones en ese objeto y por lo tanto, impedir que lo
cambien. Por lo tanto, la primera transaccin es capaz de realizar todo su
procesamiento con el conocimiento certero de que el objeto en cuestin permanecer en
un estado estable durante todo el tiempo que esta lo desee.
El sistema soporta dos tipos de bloqueos, bloqueos exclusivos o de escritura (X) y
bloqueos compartidos o de lectura (S):
-

Lock de Lectura (shared lock)

Si una transaccin slo desea leer un dato le basta asegurar que otro no escriba
sobre l en el intertanto.

Lock de Escritura (exclusive lock)

Si una transaccin quiere actualizar un dato no puede permitir ni siquiera que
alguien ms vea el dato entre medio.

T1

T2

Read(D)
D:=D+5
Write(D)

Read(D)
D:=D*3
Write(D)

T1
T2
T1
T1
T1
T1
T2
T2
T2
T2
T2

pide lock sobre D y se le otorga

pide lock sobre D y queda esperando sobre ese lock
lee D(1)
hace D=6
escribe D(6)
libera el lock sobre D lo cual libera a T2
obtiene el lock sobre D
lee D(6)
hace D=18
escribe D(18)
libera el lock sobre D

Valor final de D: 18 ... equivalente a ejecutar T1; T2

Facultad de Ingeniera

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

Funcionamiento de los locks o bloqueos

o Si la transaccin A pone un bloqueo exclusivo (X) sobre un objeto, entonces se
rechazar una peticin de cualquier otra transaccin B para un bloqueo de cualquier
tipo sobre el mismo objeto.
o Si la transaccin A pone un bloqueo compartido (S) sobre un objeto, entonces:
-

Se rechazar una peticin de cualquier otra transaccin B para un bloqueo

exclusivo (X) sobre ese objeto.

Se otorgar una peticin de cualquier otra transaccin B para un bloqueo

compartido (S) sobre ese objeto (esto es, ahora tambin B tendr un bloqueo S
sobre el objeto).

Granularidad de los locks

Los locks se pueden aplicar a distinto nivel de granularidad:
o
o
o
o

Base de Datos
Tablas
Registro
Campo

Mientras ms fina sea la granularidad, se puede soportar ms concurrencia, pero tambin

se produce una mayor prdida de tiempo y espacio.
Ejemplo de Ejecucin No Serializable
T1

T2

Read(A)
A:=A-10
Write(A)
Read B
B:=B+10
Write(B)

Read(B)
B:=B*2
Write(B)
Read(A)
A=A*3
Write(A)

T1
T1
T1
T1
T1
T2
T2
T2
T2
T2
T1
T1
T1
T1
T1
T2
T2
T2
T2
T2

pide lock sobre A y se

lee A(100)
hace A=90
escribe A(90)
libera el lock sobre A
pide lock sobre B y se
lee B(100)
hace B=200
escribe B(200)
libera el lock sobre B
pide lock sobre B y se
lee B(200)
hace B=210
escribe B(210)
libera el lock sobre B
pide lock sobre A y se
lee A(90)
hace A=270
escribe A(270)
libera el lock sobre A

le otorga

le otorga

le otorga

le otorga

Valores finales: A=270, B=210

T1; T2 produce A=270, B=220
T2; T1 produce A=290, B=210

Facultad de Ingeniera

10

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

Protocolo 2PL (2 phase lock)

Asegura la condicin de serialidad.

Consta de 2 fases:

o Crecimiento (se pueden pedir nuevos locks)

o Reduccin (slo se pueden liberar locks)

# de locks

# de locks
Cumple 2PL

No cumple 2PL

Deadlocks
Bajo esquema de control de concurrencia basado en locks debe tenerse cuidado adems
con la condicin de deadlock
T1
T2
T1
T2

pide
pide
pide
pide

lock
lock
lock
lock

sobre
sobre
sobre
sobre

A
B
B queda esperando
A queda esperando

Los dos esperan por siempre!!!

Si ocurre un deadlock, es preferible que el sistema lo detecte y lo rompa. La deteccin del
deadlock implica la deteccin de un ciclo en el grafo de espera. La ruptura implica
seleccionar una de las transacciones bloqueadas como vctima y entonces deshacerla
liberando por lo tanto todos sus bloqueos y permitiendo que continen las dems
transacciones.
En la prctica no todos los sistemas detectan los deadlocks, sino que asumen un
mecanismo de tiempo y asumen simplemente que una transaccin que no ha realizado
algn trabajo durante cierto perodo de tiempo preestablecido, est dentro de un
deadlock.
Algunos sistemas, luego de deshacer la transaccin vctima la volvern a iniciar desde el
principio, bajo la suposicin de que la condiciones que causaron el deadlock
probablemente ya no existirn.
Otros sistemas simplemente dejan el manejo de la excepcin del deadlock al programador
de la aplicacin para que la maneje de la forma que considere conveniente. En cualquiera
de los dos casos, es muy recomendable ocultar el problema al usuario final, por razones
obvias.

Facultad de Ingeniera

11

BD Bases de Datos

b.

Unidad 5: Administracin de Bases de Datos

Control de Concurrencia Optimista

Cundo usar el Control de Concurrencia Optimista
Utilizado para probabilidades de conflictos baja:
o BD muy grande y usuarios disjuntos
o Principalmente utilizada para consultas
o Muy poca actualizacin de la BD
Time Stamps
Cada transaccin recibe, al momento de iniciarse, una identificacin asociada al tiempo
de inicio (time-stamp).
La serializacin equivalente es la del orden de los time-stamp: si T1 comenz antes que
T2 ser equivalente a T1; T2 y no a T2; T1.
Cada tem de la BD tiene asociado dos valores:
o Time-stamp de ltima lectura (read-time)
o Time-stamp de ltima escritura (write-time)
Usando estos valores junto al time-stamp de la transaccin que est ejecutando es
posible asegurar lo siguiente:
No es posible que una transaccin lea un tem que otra actualiz si esta ltima parti
despus:
T1 lee X, tw(X) = t2 y t2>t1
No es posible que una transaccin escriba un tem que otra transaccin que empez
despus ya ley:
T1 escribe X, tr(X) = t2 y t2>t1

T1

T2

Read(D)
D:=D+5
Write(D)

Read(D)
D:=D*3
Write(D)

T1-1
T1-2
T2-1
T1-3
T1
T2-2
T2-3
T2
T1-1
T1-2
T1-3
T1

lee D(1)
hace D=6
lee D(1)
escribe D(6)
termina pero se encuentra un conflicto con T2 por lo cual se aborta
(escribe D(1))
hace D=3
escribe D(3)
termina y no hay conflictos
lee D(3)
hace D=8
escribe D(8)
termina y no hay conflictos

Valor final de D: 8 ... equivalente a ejecutar T2; T1

Facultad de Ingeniera

12

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

Abortos en Cascada
Una transaccin al ser abortada puede provocar el trmino de otra que ha ledo
informacin sucia.
Para saber las transacciones involucradas se utiliza la auditora bitcora (asociada al
sistema de recuperacin).
Una manera de evitar algunos de estos problemas es chequear al final (al momento del
commit) y slo entonces reflejar los cambios en forma permanente en la BD.
Cuando T termina:
o Se chequea tr de todos los tems que T desea actualizar y si existe alguno mayor
que t se aborta T.
o Se chequea el tw de todos los tems que T ha ledo y si existe alguno mayor que t
se aborta T.
o Si no se dan los casos anteriores entonces se reflejan los cambios en la BD.

Facultad de Ingeniera

13

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

Tema 3: Seguridad
En un DBMS multiusuario, ste debe proveer de mecanismos para habilitar el acceso a
ciertos usuarios (o grupos de usuarios) a partes seleccionadas de la BD y al mismo tiempo
evitar que puedan accesar el resto de la BD.
3.1. Control de Acceso Discrecionario
Basado en otorgacin y anulacin de privilegios. El DBMS provee acceso selectivo a cada
relacin basado en usuarios (cuentas) especficos.
El tener una cuenta no entrega automticamente toda la funcionalidad del DBMS a su dueo
(operaciones tambin son controladas).
Credenciales de un Usuario o Cuenta
Para crear un usuario o una cuenta se deben definir sus credenciales. Las credenciales son
los atributos de una cuenta que sirven para identificarla de manera nica:
o Username: Nombre de usuario o cuenta.
o Host: Ubicacin desde donde se le permite conectar al usuario. El host puede tener
tres tipos de valores:
o Localhost: El usuario o cuenta slo puede conectarse desde la misma mquina
donde est funcionando el servidor de bases de datos.
o Remoto (%): El usuario puede conectarse desde cualquier terminal o mquina
remota al servidor de bases de datos.
o Direccin IP: El usuario slo puede conectarse desde una ubicacin especfica
determinada con un URL o direccin IP.
o Password: Contrasea de seguridad del usuario. Esta contrasea suele ser
encriptada con distintos tipos de hashing unidireccionales (por ejemplo, en el caso
de MySQL se hace utilizando el algoritmo de encriptacin MD5).
Privilegios de una Usuario o Cuenta
Los privilegios definen el nivel de acceso que un usuario o cuenta tienen sobre un servidor de
bases de datos. Estos privilegios puede definirse a nivel de cuenta independientemente de
las relaciones o bases de datos presentes (privilegios globales) o a niveles ms detallados: a
nivel de base de datos, a nivel de tablas, a nivel de campos.
En todos estos niveles puede especificarse las acciones para las que el usuario est
autorizado. Estas acciones pueden ser a nivel de DDL (Create, Alter y Drop) y a nivel de DML
(Select, Insert, Update, Delete). Dentro de cada nivel tambin puede definirse si se le otorga
al usuario la posibilidad de entregar acceso a otros usuarios sobre los objetos sobre los que
ha recibido privilegios.
El DBA es un usuario con privilegios globales totales con capacidad de crear usuarios y de
otorgar permiso sobre todos los objetos presentes en el servidor de bases de datos.
Los privilegios a nivel de cuenta (privilegios globales) son especificados por el DBA
para cada cuenta independientemente de las relaciones en la BD:
o CREATE DATABASE: Permite crear nuevas bases de datos en el servidor. Un
usuario que crea una base de datos se convierte en dueo de dicha base de
datos, lo que le permite alterarla o eliminarla sin restriccin.
o CREATE TABLE: Permite crear nuevas tablas en cualquier base de datos del
servidor.
o CREATE VIEW: Permite crear vistas de cualquier base base de datos en el
servidor.
o ALTER: Permite alterar la estructura de cualquier base de datos en el servidor.
o DROP: Permite eliminar componentes de la estructura de cualquier base de
datos en el servidor.
o SELECT: Permite consultar cualquier base de datos en el servidor.

Facultad de Ingeniera

14

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

Los privilegios a nivel de relacin permiten el acceso a las distintas bases de datos
del servidor. Estos privilegios dependen del nivel al que se asigna acceso:
o Privilegios a nivel de Base de Datos: Acciones permitidas dentro de la base de
datos a la que se est otorgando privilegios:
CREATE TABLE
DROP TABLE
ALTER TABLE
SELECT
INSERT
UPDATE
DELETE
o Privilegios a nivel de Tablas: Acciones permitidas dentro de la tabla especfica
de la base de datos a la que se est otorgando privilegios:
ALTER TABLE
SELECT
INSERT
UPDATE
DELETE
o Privilegios a nivel de Campos: Acciones permitidas dentro del campo de una
tabla especfica de la base de datos a la que se est otorgando privilegios:
SELECT
UPDATE

Otorgamiento de privilegios
Para entregar privilegios a un usuario o cuenta se utiliza el comando GRANT, que tiene la
siguiente estructura:
GRANT privilegios ON objeto TO usuario [WITH GRANT OPTION]
privilegios: lista de privilegios create, alter, drop, select, insert, update, delete que
se entregarn al usuario.
objeto:
lista de bases de datos, tablas o campos sobre los que se otorgar
privilegios.
usuario:
usuario al que se est otorgando los privilegios.
[WITH GRANT OPTION] clusula opcional que permite al usuario receptor de
privilegios, otorgar los mismos privilegios a otro usuario.
Retiro de privilegios
Para retirar privilegios a un usuario o cuenta se utiliza el comando REVOKE, que tiene la
siguiente estructura:
REVOKE privilegios ON objeto TO usuario
Cuando se le retiran los privilegios a un usuario que a su vez ha entregado privilegios a otros
usarios, automticamente estos ltimos pierden dichos privilegios.

Facultad de Ingeniera

15

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

Un ejemplo
DBA crea 4 cuentas A1, A2, A3 y A4

Se desea que slo A1 pueda crear relaciones

GRANT CREATE TABLE TO A1;
A1 crea dos relaciones:
EMPLEADO(Nombre, NSS, Fec_Nac, Direccin, Sexo, Suelo, Dpto)
Departamento(Dpto, Nombre, MGRSSN)

A1 desea otorgar a A2 privilegios para insertar y eliminar tuplas en ambas

relaciones:
GRANT INSERT, DELETE ON EMPLEADO, DEPARTAMENTO TO A2;
A2 no puede a su vez traspasar privilegios a terceros (sin GRANT OPTION)

A1 quiere ahora hacer que A3 pueda consultar ambas tablas y si lo desea otorgar
este mismo derecho a quien estime conveniente
GRANT SELECT ON EMPLEADO, DEPARTAMENTO TO A3 WITH GRANT
OPTION;

A3 otorga privilegio de lectura para EMPLEADO a A4 :

GRANT SELECT ON EMPLEADO TO A4

A1 elimina privilegio de lectura para EMPLEADO a A3:

REVOKE SELECT ON EMPLEADO TO A3
(DBMS elimina tambin el privilegio de A4)

A1 desea otorgar nuevamente a A3 privilegio de lectura pero en forma limitada (slo

nombre, fecha de nacimiento y direcciones de empleados del Dpto # 5)
A1 debe crear una vista:
CREATE VIEW A3EMPLEADO AS
SELECT Nombre, Fec_Nac, Direccion
FROM EMPLEADO
WHERE Dpto = 5
GRANT SELECT ON A3EMPLEADO TO A3 WITH GRANT OPTION;

A1 quiere ahora autorizar a A4 a actualizar el campo de sueldos de EMPLEADO

GRANT UPDATE ON EMPLEADO.Sueldo TO A4;
Nota:
UPDATE e INSERT pueden especificar atributos. SELECT y DELETE no pueden
(debe usarse una vista)
Si A3 ha recibido el mismo privilegio de A1 y A4 y uno de ellos lo revoca, A3 sigue
teniendo el privilegio (lo perdera si el segundo tambin lo revoca)

Facultad de Ingeniera

16

BD Bases de Datos

Unidad 5: Administracin de Bases de Datos

3.2. Control de Acceso Obligatorio

La mayora de los DBMS comerciales no tienen soporte de este tipo de mecanismos.
Los datos y los usuarios se clasifican en clases o niveles de seguridad (para usuarios
clearence, para objetos classification).
TS top secret
S secret
C confidential
U unclassified

o
o
o
o

Clearence (S) nivel del sujeto S

Class (O) clasificacin del objeto O
Reglas del control de acceso obligatorio
1. No se entrega a S acceso de lectura a O a menos que clearence(S) >= class(O)
2. No se otorga a S acceso de escritura a O a menos que clearence(S) = class(O)
(cualquier item escrito por un usuario con clearence=i adquiere clasificacin i)
La idea de la segunda regla es que un usuario con alto nivel no puede bajar la
clasficacin de un tem.
Funcionamiento del control de acceso obligatorio
A cada objeto de una base de datos (tabla, tupla o campo) se le asocia un atributo de
clasificacin.
As, una relacin quedara expresada por el siguiente esquema:
Relacin = { Campo1, Class1, Campo2, Class2, ... Campon, Classn, Classtupla}
Ejemplo:
Nombre

Sueldo

Desempeo

Classtupla

Prez U
Robles C

40000 C
80000 S

Aceptable S
Bueno
C

U
C

SELECT * FROM EMPLEADO

Usuario con Clearance nivel C obtiene
Nombre

Sueldo

Desempeo

Prez U
Robles C

40000 C
null
S

null
Bueno

S
C

Classtupla
U
C

Usuario con Clearance nivel U obtiene

Nombre

Sueldo

Prez U

null

Facultad de Ingeniera

Desempeo
C

null

Classtupla
U

17