OpoTests/Public/md/gemini/post/054.bases-de-datos.md
2026-03-06 20:26:06 +01:00

4.5 KiB

📝 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:

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

En SQL Server:

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

En SQL Server a partir de Roles:

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.