> **📝 EXAME TÉCNICO: ADMINISTRACIÓN DE BBDD (Temas 16, 17 e 18)**

# 1. TEST CON XUSTIFICACIÓN (Tema 17: Optimización)

Nunha base de datos relacional, que tipo de índice sería máis axeitado para unha columna con valores únicos e que se utiliza frecuentemente en buscas por rangos (ex. datas)?

- A) Índice Hash.
- B) Índice B-Tree (Árbore-B).
- C) Índice Bitmap.

Xustificación: (Por que as outras non son ideais para "rangos"?)

## Resposta

A pechas eu diría que a A por mor de seren o máis lóxico por termos pois o que queres que facer unha xestión adeita a valores que poden ser grandes pero Hasheados éstes son máis curtos na orde para xestiona-los índices. Neste caso, non é que sexa un Hash como tal, senon que Tokenízase o valor para orde e busca por Tokenización.

- A) O entendo como orden por Tokenización.
- B) Aquí entendo un sistema relacional, é dicir, cando relacionas unha táboa con outra queda en árbore pola relación 1:N.
- C) Aquí viriamos a ver unha xestión de imaxe, que nin se quere creo que poida existir como índice nun motor de datos deste estilo.

## Corrección

- **¡OLLO AQUÍ!** 🚩
- **A resposta correcta era a B (B-Tree).**
- **Corrección**: O **Índice Hash** só serve para buscas de igualdade (`WHERE data = '2023-01-01'`). Como o hash desordena os valores orixinais, **non serve para rangos** (`>`,`<`,`BETWEEN`). O **B-Tree (Árbore-B)** mantén os datos ordenados e balanceados, permitindo saltar rapidamente a un punto e ler todos os seguintes.
- **Dato extra**: O **Bitmap** existe e úsase moito en Data Warehousing para columnas con poucos valores distintos (ex: Sexo, Estado Civil), pero non para valores únicos como di a pregunta.

# 2. RESPOSTA CURTA (Tema 18: Backups)

Define brevemente a diferenza entre un "Backup Diferencial" e un "Backup Incremental" en canto ao que gardan respecto á última copia.

## Resposta

O BackUp Diferencial fai copia dos cambios que puideron haber dende a última copia completa; mentras que a incremental fai instantáneas cos cambios con respecto á última feita, independentemente do tipo de copia sexa. É dicir, na copia diferencial parte sempre con respecto á última copia compreta; mentres que a incremental parte sempre da última, independentemente do tipo. Por esta vía, cara a súa xeración o incremental é a máis lixeira e rápida; pero cara a súa restauración, a Diferencial é a máis rápida e fiable.

> **Anotación**: Pese á miña vergoña, tiven que tirar de mirar. A verdade que nin me acordaba pese a habelo estudiado vai tempo.

## Corrección

- **Correcta**.
- Explicaches perfectamente a filosofía: **Diferencial** (acumula dende a última completa) vs **Incremental** (só dende a última de calquera tipo).
- A túa conclusión sobre a restauración é de 10: a Diferencial é máis rápida de restaurar porque só necesitas 2 pezas (Completa + Última diferencial), mentres que na Incremental necesitas toda a cadea.

# 3. DESENVOLVEMENTO "FLASH" (Tema 16: Seguridade)

Se tiveses que aplicar o "Principio de Menor Privilexio" (Least Privilege) na creación dun novo usuario para unha aplicación que só necesita ler e inserir datos nunha táboa de 'Rexistros', que sentenzas SQL (DCL) básicas usarías e por que non lle darías o rol de 'db_owner'?

## Resposta

Se a base de datos vai estructurada a procedementos almaceados e non a consultas, só lle daría permiso de execución; pero pola contra, se ésta baséase nun sistema de consultas, lle daría permiso específico de selección e inserción, sen máis miramentos por mor de seren as accións específicas dadas. O `db_owner` ven sendo darlle permisos de propietario e iso darialle un acceso de control total cara dita base de datos.

En MySQL/MariaDB, Postgres:

```sql
create user 'USUARIO'@'HOST' identified by 'CONTRASINAL';
grant select, insert on BASE_DE_DATOS.* to 'USUARIO'@'HOST';
flush privileges;
```

En SQL Server:

```sql
create user USUARIO with password = 'CONTRASINAL'
grant select, insert on dbo.BASE_DE_DATOS to USUARIO
```

En SQL Server a partir de Roles:

```sql
create user USUARIO with password = 'CONTRASINAL'
create role ROL
grant select, insert dbo.BASE_DE_DATOS to ROL
alter role ROL add member USUARIO
```

En SQLite no se gestionan usuarios pues su interacción se basa en el entorno de ejecución.

## Corrección

- **Excelente**.
- Moi bo matiz sobre os procedementos almacenados (`EXECUTE`).
- As sentenzas SQL están perfectas, incluíndo o `FLUSH PRIVILEGES` de MySQL (que moita xente esquece).
- O de **SQLite** é un detalle de "pro" que demostra que sabes de que falas.