83 lines
4.5 KiB
Markdown
83 lines
4.5 KiB
Markdown
> **📝 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. |