09/03/2020

1
 09/03/2020

De las fases de diseño de una base de datos, el conceptual y lógico

define el "qué" queremos representar y almacenar, y el físico el "cómo"
hacerlo.

2
 09/03/2020

Ya visto en presentación SGBD, recordatorio de los niveles ANSI/SPARC

y la independencia entre esquemas.

3
 09/03/2020

El concepto de transacción como proceso o programa ejecutable con

varios accesos a la base de datos, bien sea para leer o para escribir en
ella. Es requisito indispensable que los estados de base de datos inicial y
final sean correctos desde el punto de vista de la integridad de datos.

Esto implica que una transacción se ejecuta totalmente o se revierte al

estado inicial —se deshace lo ejecutado hasta el momento del error—.
Por eso las transacciones se confirman al final (commit) o se revierten
(rollback).

4
 09/03/2020

Un sistema transaccional cumple con las propiedades ACID.

Atomicidad: el conjunto de órdenes de una transacción se ve y se trata
como una única instrucción.
Consistencia: antes y después de ejecutar la transacción la base de datos
y sus datos son correctos.
Aislamiento: unas transacciones no interfieren con otras en ejecuciones
concurrentes —no generan datos erróneos—.
Durabilidad: el resultado de una transacción es persistente.

5
 09/03/2020

En el contexto que hemos comentado en las diapositivas anteriores, el

diseño físico busca
Mejorar —o conseguir dentro de lo razonable— los tiempos de respuesta
Aprovechar el espacio en disco —recordemos que una BD puede
almacenar terabytes y petabytes de datos.
Obtener la mejor productividad de transacciones posible.

6
 09/03/2020

El diseño físico se alimenta, principalmente, del diseño lógico (tablas,

columnas y restricciones), pero también de
las ejecuciones (accesos) más frecuentes o esperadas
las demandas de los usuarios

7
 09/03/2020

Con eso definimos el esquema que define la BD en un SGBD concreto,

cómo se van a gestionar sus estructuras en disco duro, y los índices que
sean necesarios.
Además se tomarán decisiones de rediseño en función de las
necesidades de rendimiento detectadas (desnormalización), y se
monitorizará el sistema.

8
 09/03/2020

El conjunto de órdenes sql de definición y la carga de datos.

Puede haber varias alternativas dependiendo de justo de lo comentado en
la diapositiva anterior.

9
 09/03/2020

Hablando en particular de los índices, descripción del entorno de

ejecución de cualquier consulta. El optimizador define varios planes de
ejecución, básicamente el orden en que utilizará las tablas requeridas y
los índices disponibles. De todos esos planes elegirá el que crea óptimo y
lo ejecutará. Todo esto es transparente para el usuario —aunque puede
consultar el plan y hasta modificarlo si así lo quiere hacer; de hecho, el
optimizador no siempre acierta—.

10
 09/03/2020

Hay que entender que "posición" es una referencia física a una posición
dentro de un fichero en un disco duro.

11
 09/03/2020

Los índices no densos necesitan que el fichero de datos esté ordenado

por la clave. Un índice denso permite tenerlo desordenado. Esto afecta
directamente al rendimiento de las operaciones de inserción, borrado y
modificación.

12
 09/03/2020

Hay mucho otros.

El ejemplo de arriba a la derecha es de un árbol-B. Una estructura de
este tipo se recorre recursivamente desde la raíz hasta encontrar la
referencia a la clave buscada.

El de abajo, de una tabla hash, calcula un valor limitado a un rango entre

0 y x en base a los valores de clave. Por ejemplo, “Lisa Smith” “vale” 1 y
“John Smith” 152. Así, estos valores de clave y la dirección física en el
fichero de datos del registro asociado se ordenan en un array de x
posiciones. Dada esta limitación, puede darse el caso de que haya más
datos que posiciones en el array, por lo que varios valores de clave
pueden obtener el mismo valor hash. Para esos casos se utilizan los
registros de desbordamiento. Si hay muchos desbordamientos,
seguramente será aconsejable hacer más grande el array y aplicar otra
función hash para recalcular dónde va cada dato.

13
 09/03/2020

Obviamente, el uso de las estructuras de índice tiene un coste. Las

lecturas se agilizan pero el resto de órdenes se ralentizan, tienen que
acceder a dos estructuras. Se supone que ganamos más que perdemos.

14
 09/03/2020

Los índices de clave primaria, por ejemplo, los crea automáticamente el

SGBD —o que cuando decidimos cuál es la clave primaria ya estamos
definiendo un índice—, pero podemos definir más índices. En este
ejemplo, se supone que es una consulta que se ejecuta habitualmente por
lo que esas columnas del where son candidatas claras para indizar.

15
 09/03/2020

Otro de los aspectos de mejora del rendimiento mencionados es la

desnormalización.

16
 09/03/2020

Hay mucho casos susceptibles de desnormalización. Este es uno de

ellos. Esta es la definición que representa una relación 1:1.

17
 09/03/2020

Esto implica que cualquier consulta que pida datos de una y otra tabla
base obliga al join de 3 tablas.

18
 09/03/2020

Si no hay otras consideraciones que lo desaconseje, se puede eliminar la

tercera tabla y colocar la clave ajena en una de las tablas. Puesto que en
SQL no existe la clave alternativa, la solución es definir un índice único —
sin duplicados— pero que admita nulos.
Un ejemplo más de que la implementación del nulo en los SGBD no se
ajusta a la teoría —lo que no necesariamente es malo—.

19
 09/03/2020

Pero antes de tomar esta decisión debemos tener en cuenta el

comportamiento futuro y esperado de los datos.

20
 09/03/2020

Otro caso típico. Esta es la definición de una 1:N y una consulta típica.

21
 09/03/2020

Si es muy, muy habitual esta consulta, ¿porqué no duplicar la columna?

Eso nos evita un join. Nuevamente, esta desnormalización no se hace
porque sí, tiene que estar justificada.

22
09/03/2020

23
09/03/2020

24
09/03/2020

25