Tarea 1:

1. Comenta brevemente:
a. Define brevemente el efecto de cada nivel de aislamiento:

READ UNCOMMITTED​ puede recuperar datos modificados pero no confirmados por otras
transacciones (lecturas sucias - dirty reads).

READ COMMITTED​ permite que entre dos lecturas de un mismo registro en una transacción A,
otra transacción B pueda modificar dicho registro, obteniendose diferentes resultados de la
misma lectura.

REPEATABLE READ​ evita que entre dos lecturas de un mismo registro en una transacción A,
otra transacción B pueda modificar dicho registro, con el efecto de que en la segunda lectura de
la transacción A se obtuviera un dato diferente.

SERIALIZABLE​ garantiza que una transacción recuperará exactamente los mismos datos cada
vez que repita una operación de lectura (es decir, la misma sentencia SELECT con la misma
cláusula WHERE devolverá el mismo número de filas, luego no se podrán insertar filas nuevas
en el rango cubierto por la WHERE, etc. - se evitarán las lecturas fantasma), aunque para ello
aplicará un nivel de bloqueo que puede afectar a los demás usuarios en los sistemas
multiusuario (realizará un bloqueo de un rango de índice - conforme a la cláusula WHERE - y si
no es posible bloqueará toda la tabla). Evita los problemas de las lecturas sucias (dirty reads),
de las lecturas no repetibles (non repeatable reads), y de las lecturas fantasma (phantom
reads).

b. Describe brevemente las siguientes anomalías:

I. Lecturas sucias:
Las lecturas sucias (o lecturas no confirmadas) son lecturas de filas que están siendo
modificadas por una transacción abierta.

II. Lecturas no repetibles:

Una lectura no repetible ocurre cuando en el curso de una transacción una fila se lee dos veces
y los valores no coinciden.

III. Registros fantasmas

Los registros que se eliminan de un nivel hoja de una página de índice no se quitan físicamente
de la página; en su lugar, el registro se marca como "para eliminar" o fantasma. Esto significa
que la fila se conserva en la página pero se cambia una parte del encabezado de fila para
indicar que la fila es realmente un fantasma. Esto sirve para optimizar el rendimiento durante
una operación de eliminación.
 c. Enumera los estados de una transacción:

Activa​ (estado inicial): la transacción permanece en este estado durante su ejecución.

Parcialmente​ Comprometida: la transacción pasa a este estado cuando acaba de realizar la
última instrucción.
Fallida​: la transacción pasa a este estado tras descubrir que no puede continuar la ejecución
normal.
Abortada​: la transacción pasa a este estado después de haber restablecido la base de datos a
su estado anterior.
Comprometida​: la transacción pasa a este estado tras completarse con éxito.

2. Diseña la base de datos que aplique al siguiente caso:

A. La empresa XY tiene varios vehículos de uso interno y varios choferes,

necesita controlar o saber el chofer que utiliza un determinado vehículo en un determinado
momento, teniendo en cuenta que un vehículo puede ser utilizado por más de un chofer.
Dentro del sistema cada chofer se identifica por un número, pero la licencia puede ser también
un valor para identificarlo.

C. Diagrama Entidad Relación:

D. Modelo Lógico:

E. Diseño Físico (​En el diseño físico aplica todas las restricciones de integridad que
apliquen.​):

1) Creamos la base de datos y el esquema:

CREATE TABLE tarea2

Go

CREATE SCHEMA tarea

Go

2) Creamos la tabla chofer:

create table tarea.chofer

(
ID int identity,
nombre varchar(50) not null,
apellido varchar(50) not null,
licencia varchar(50) not null
)
go
create unique index chofer_ID_uindex
on tarea.chofer (ID)
go

create unique index chofer_licencia_uindex

on tarea.chofer (licencia)
go

alter table tarea.chofer

add constraint chofer_pk
primary key nonclustered (ID)
go

3) Creamos la tabla coche:

create table tarea.coche

(
ID int identity,
marca varchar(50) not null,
modelo varchar(50),
matricula varchar(50) not null
)
go

create unique index coche_ID_uindex

on tarea.coche (ID)
go

create unique index coche_matricula_uindex

on tarea.coche (matricula)
go

alter table tarea.coche

add constraint coche_pk
primary key nonclustered (ID)
go

4) Creamos la tercera tabla para manejar horarios:

create table tarea.horario

(
ID int identity,
 ID_coche int
constraint horario_coche_ID_fk
references tarea.coche,
ID_chofer int
constraint horario_chofer_ID_fk
references tarea.chofer,
Horario DATETIME
)
go

create unique index horario_ID_uindex

on tarea.horario (ID)
go

alter table tarea.horario

add constraint horario_pk
primary key nonclustered (ID)
go