Módulo 03: Sistemas gestores de bases de datos

Objetivos del módulo

  • Definir qué es un sistema gestor de bases de datos (SGBD) y diferenciarlo de la base de datos
  • Conocer los objetivos y las funciones de un SGBD: definición, manipulación, control, integridad, seguridad, concurrencia, recuperación y diccionario de datos
  • Comprender la arquitectura ANSI/SPARC de tres niveles (externo, conceptual e interno) y aplicarla a un ejemplo concreto
  • Distinguir entre independencia lógica e independencia física de los datos
  • Diferenciar esquema y ejemplar (instancia) de una base de datos
  • Identificar los componentes internos de un SGBD y el recorrido de una consulta por ellos
  • Clasificar los lenguajes de un SGBD: DDL, DML (procedimental y no procedimental), DCL, TCL y lenguajes anfitriones
  • Conocer los distintos usuarios y roles que interactúan con una base de datos
  • Entender qué es una transacción y las propiedades ACID
  • Conocer las arquitecturas de los sistemas de bases de datos: centralizada, cliente/servidor, dos y tres capas, distribuida
  • Comparar los principales SGBD del mercado
  • Conocer a nivel conceptual la arquitectura de Oracle Database: instancia y base de datos, arquitectura multitenant (CDB y PDB), usuarios y esquemas, ediciones y versiones

1. ¿Qué es un SGBD?

1.1. Definición

En el módulo 00 viste que una base de datos es una colección de datos integrados, persistentes y compartidos. Pero los datos, por sí solos, no hacen nada: hace falta un software que los organice, los proteja y atienda las peticiones de los usuarios. Ese software es el SGBD.

📘 Concepto: Un sistema gestor de bases de datos (SGBD; en inglés Database Management System, DBMS) es un conjunto de programas que permite definir, construir, manipular, controlar y compartir bases de datos entre diversos usuarios y aplicaciones, garantizando la integridad, la seguridad, la concurrencia y la recuperación de los datos, y proporcionando independencia entre los datos y los programas que los usan.

Recuerda la analogía del módulo 00: la base de datos es la biblioteca (los libros ordenados) y el SGBD es el bibliotecario, que sabe dónde está cada libro, decide quién puede llevárselo, evita que dos personas se lleven el mismo ejemplar y repara los daños.

1.2. Base de datos frente a SGBD

Aspecto Base de datos SGBD
Qué es Los datos (y su descripción) El software que los gestiona
Ejemplo Las tablas del esquema EMPRESA con sus filas Oracle AI Database 26ai
Dónde reside En ficheros, en almacenamiento persistente En memoria (procesos en ejecución) y en ficheros de programa
Se diseña o se instala Se diseña (bloques 2 y 3 del curso) Se instala y se configura (módulo 22)
Cambia Continuamente (cada inserción, cada modificación) Al actualizar de versión o aplicar parches
Relación Un SGBD puede gestionar muchas bases de datos Una base de datos la gestiona un SGBD

⚠️ Importante: En el lenguaje cotidiano se dice “instalar la base de datos” o “la base de datos se ha caído” cuando se habla del SGBD. Es un uso aceptado, pero en un contexto técnico o en un examen distingue siempre ambos conceptos.

2. Objetivos y funciones de un SGBD

2.1. Objetivos

Los SGBD nacieron para resolver los problemas de los sistemas de ficheros (módulo 01). Sus objetivos son, por tanto, el reverso de aquellos problemas:

Objetivo Problema de los ficheros que resuelve
Abstracción de la información: el usuario no necesita saber cómo se almacenan físicamente los datos Dependencia física
Independencia de los datos respecto a los programas Dependencia física
Redundancia mínima y controlada Redundancia
Consistencia de los datos Inconsistencia
Integridad: los datos cumplen las reglas definidas Integridad
Seguridad: solo acceden quienes están autorizados, y solo a lo que deben Seguridad
Concurrencia: muchos usuarios trabajan a la vez sin interferir Acceso concurrente
Recuperación ante fallos Atomicidad, pérdida de datos
Facilidad de acceso: lenguajes de consulta para preguntas no previstas Dificultad de acceso
Tiempo de respuesta adecuado Rendimiento

2.2. Funciones

Para cumplir esos objetivos, un SGBD ofrece un conjunto de funciones:

Función de definición (descripción)

Permite especificar la estructura de la base de datos: tipos de datos, tablas, columnas, relaciones, restricciones, vistas, índices. Esta descripción se hace con el lenguaje de definición de datos (DDL) y se almacena en el diccionario de datos. Abarca los tres niveles de la arquitectura (externo, conceptual e interno) que verás en el apartado 3.

Función de manipulación

Permite consultar (recuperar) y actualizar (insertar, modificar y borrar) los datos. Se realiza con el lenguaje de manipulación de datos (DML).

Función de control

Agrupa las tareas que garantizan que la base de datos funciona correctamente y de forma segura:

Subfunción Descripción Ejemplo en Oracle
Integridad Comprobar que los datos cumplen las restricciones definidas (claves, valores válidos, referencias) Rechazar un empleado con salario negativo por la restricción ck_emp_salario
Seguridad Autenticar a los usuarios y controlar qué puede hacer cada uno sobre cada objeto El usuario becario solo puede consultar PRODUCTOS, no modificarla
Concurrencia Coordinar el acceso simultáneo de muchos usuarios evitando interferencias Bloquear la fila de un cliente mientras se modifica
Recuperación Restaurar la base de datos a un estado correcto tras un fallo (de transacción, de sistema o de disco) Tras un corte de luz, deshacer las transacciones no confirmadas y rehacer las confirmadas
Auditoría Registrar quién hace qué y cuándo Anotar todos los accesos a la tabla de nóminas

Función de diccionario de datos

📘 Concepto: El diccionario de datos (o catálogo) es una base de datos interna del SGBD que contiene los metadatos: la descripción de todos los objetos (tablas, columnas, tipos, restricciones, vistas, índices), de los usuarios y sus privilegios, del almacenamiento y de las estadísticas que usa el optimizador.

El SGBD consulta el diccionario constantemente: para comprobar que una tabla existe, que el usuario tiene permiso, que un valor cumple una restricción o para decidir cómo ejecutar una consulta. En Oracle, el diccionario se puede consultar con SQL mediante vistas como USER_TABLES, ALL_TAB_COLUMNS o DBA_USERS (módulo 26).

-- Ejemplo ilustrativo: qué tablas tengo y cuántas filas tenían en el último análisis
SELECT table_name, num_rows
FROM   user_tables
ORDER BY table_name;

Otras funciones (utilidades)

  • Carga y descarga de datos (en Oracle: SQL*Loader, Data Pump).
  • Copias de seguridad y restauración (en Oracle: RMAN).
  • Monitorización y ajuste del rendimiento.
  • Reorganización del almacenamiento.
  • Herramientas de desarrollo e interfaces (en Oracle: SQL*Plus, SQLcl, SQL Developer).

3. La arquitectura ANSI/SPARC de tres niveles

3.1. Origen

En 1975, el comité ANSI/X3/SPARC (Standards Planning and Requirements Committee del organismo de normalización estadounidense ANSI) publicó un informe provisional, completado en 1978 (Tsichritzis y Klug), que proponía una arquitectura de referencia para los SGBD. Aunque ningún SGBD comercial la implementa al pie de la letra, es el marco conceptual con el que se explican todos.

Su idea central es separar la visión que tienen los usuarios de los datos de la forma en que se almacenan físicamente, mediante tres niveles de abstracción, cada uno descrito por un esquema.

3.2. Los tres niveles 

flowchart TB
    U1["Usuario / aplicación<br/>de Recursos Humanos"] --> E1["Esquema externo 1<br/>(vista de RR. HH.)"]
    U2["Usuario / aplicación<br/>de Ventas"] --> E2["Esquema externo 2<br/>(vista de Ventas)"]
    U3["Usuario / aplicación<br/>Directorio"] --> E3["Esquema externo 3<br/>(vista del directorio)"]
    E1 --> C["ESQUEMA CONCEPTUAL<br/>(toda la BD: entidades, atributos,<br/>relaciones, restricciones)"]
    E2 --> C
    E3 --> C
    C --> I["ESQUEMA INTERNO<br/>(ficheros, bloques, índices,<br/>organización física)"]
    I --> BD[("Base de datos<br/>almacenada")]
    subgraph NE["Nivel externo"]
        E1
        E2
        E3
    end
    subgraph NC["Nivel conceptual"]
        C
    end
    subgraph NI["Nivel interno"]
        I
    end
Nivel Describe Quién lo usa Cuántos hay Pregunta que responde
Externo (de usuario, de visión) La parte de la BD que interesa a un usuario o grupo, tal como la quiere ver Usuarios finales y programadores Muchos (uno por cada tipo de usuario o aplicación) ¿Qué datos ve este usuario y con qué forma?
Conceptual (lógico global) Toda la base de datos: qué datos hay, cómo se relacionan y qué restricciones cumplen, sin detalles físicos DBA y diseñadores Uno ¿Qué datos hay en la organización?
Interno (físico) Cómo se almacenan los datos: ficheros, registros, índices, bloques, compresión, rutas de acceso DBA y el propio SGBD Uno ¿Cómo y dónde se guardan?

💡 Consejo: Piensa en un edificio de oficinas. El nivel interno son las tuberías, el cableado y la estructura de hormigón (solo le interesan al arquitecto y a mantenimiento). El nivel conceptual es el plano completo de todas las plantas. El nivel externo es lo que ve cada empresa inquilina: solo su planta, con su decoración y sus carteles, sin saber nada de las demás.

3.3. Correspondencias (mappings) entre niveles

Entre cada par de niveles adyacentes, el SGBD mantiene una correspondencia (o regla de transformación) que traduce las peticiones y los datos de un nivel al otro:

  • Correspondencia externa/conceptual: indica cómo se obtiene cada elemento de un esquema externo a partir del esquema conceptual (por ejemplo, que la columna “sueldo_anual” de una vista es salario * 14 de la tabla EMPLEADOS).
  • Correspondencia conceptual/interna: indica cómo se almacena físicamente cada elemento del esquema conceptual (por ejemplo, que la tabla EMPLEADOS está en el tablespace USERS, en tales ficheros, con un índice B-tree sobre email).

Cuando un usuario hace una consulta sobre su esquema externo, el SGBD la traduce al nivel conceptual y de ahí al interno; los resultados recorren el camino inverso.

3.4. Ejemplo concreto con el esquema EMPRESA

Veamos los tres niveles para una parte del esquema EMPRESA: los empleados y sus departamentos.

Nivel conceptual. Describe todas las tablas, todas sus columnas, sus tipos y sus restricciones. En Oracle se expresa con CREATE TABLE (lo aprenderás en los módulos 23 y 24):

-- Ejemplo ilustrativo (versión resumida de empresa_crear.sql)
CREATE TABLE empleados (
    emp_id      NUMBER(6)     CONSTRAINT pk_empleados PRIMARY KEY,
    nombre      VARCHAR2(30)  CONSTRAINT nn_emp_nombre NOT NULL,
    apellidos   VARCHAR2(50)  CONSTRAINT nn_emp_apellidos NOT NULL,
    email       VARCHAR2(60)  CONSTRAINT nn_emp_email NOT NULL,
    telefono    VARCHAR2(15),
    fecha_alta  DATE          CONSTRAINT nn_emp_fecha_alta NOT NULL,
    oficio      VARCHAR2(30)  CONSTRAINT nn_emp_oficio NOT NULL,
    salario     NUMBER(8,2)   CONSTRAINT nn_emp_salario NOT NULL,
    comision    NUMBER(8,2),
    jefe_id     NUMBER(6),
    dept_id     NUMBER(4),
    CONSTRAINT uq_emp_email   UNIQUE (email),
    CONSTRAINT ck_emp_salario CHECK (salario > 0),
    CONSTRAINT fk_emp_jefe    FOREIGN KEY (jefe_id) REFERENCES empleados (emp_id),
    CONSTRAINT fk_emp_dept    FOREIGN KEY (dept_id) REFERENCES departamentos (dept_id)
);

O, en la notación del esquema relacional que usarás en el bloque 3:

EMPLEADOS (emp_id, nombre, apellidos, email, telefono, fecha_alta, oficio, salario, comision, jefe_id, dept_id)

  • jefe_id → EMPLEADOS(emp_id)
  • dept_id → DEPARTAMENTOS(dept_id)
  • UK: email

DEPARTAMENTOS (dept_id, nombre, localidad, presupuesto)

Nivel externo. Cada grupo de usuarios ve solo lo que necesita. En SQL, los esquemas externos se implementan sobre todo con vistas (módulo 26) y con privilegios (módulo 37):

-- Ejemplo ilustrativo. Esquema externo 1: Recursos Humanos ve los datos salariales
CREATE VIEW v_rrhh_empleados AS
SELECT e.emp_id, e.nombre, e.apellidos, e.fecha_alta, e.oficio,
       e.salario, e.comision, e.salario * 14 AS sueldo_anual,
       d.nombre AS departamento
FROM   empleados e
       LEFT JOIN departamentos d ON d.dept_id = e.dept_id;

-- Esquema externo 2: el directorio interno NO ve salarios ni comisiones
CREATE VIEW v_directorio AS
SELECT e.nombre || ' ' || e.apellidos AS empleado,
       e.email, e.telefono, d.nombre AS departamento, d.localidad
FROM   empleados e
       LEFT JOIN departamentos d ON d.dept_id = e.dept_id;

Observa que la vista de RR. HH. tiene una columna, sueldo_anual, que no existe en el nivel conceptual: se calcula (es la correspondencia externa/conceptual). Y que el directorio ve el nombre completo en una sola columna, aunque en el nivel conceptual son dos.

Nivel interno. Describe cómo se guardan físicamente los datos. Parte de esa descripción la decide el DBA y parte el propio SGBD:

-- Ejemplo ilustrativo: decisiones del nivel interno
-- Un índice para acelerar las búsquedas de empleados por departamento
CREATE INDEX ix_emp_dept ON empleados (dept_id);

Y el resto de los detalles internos son invisibles para el usuario: la tabla EMPLEADOS se guarda en el tablespace USERS, que corresponde a un fichero de datos users01.dbf; sus filas ocupan bloques de 8 KB; la restricción uq_emp_email se apoya en un índice B-tree creado automáticamente; etc.

Elemento Nivel externo Nivel conceptual Nivel interno
Ejemplo Vistas v_rrhh_empleados, v_directorio Tablas EMPLEADOS, DEPARTAMENTOS con todas sus columnas y restricciones Tablespace USERS, fichero users01.dbf, bloques de 8 KB, índices B-tree
Lo ven Cada departamento, su vista El DBA y los diseñadores El DBA y el SGBD
Se define con CREATE VIEW, GRANT CREATE TABLE, restricciones CREATE INDEX, CREATE TABLESPACE, parámetros de almacenamiento

4. Independencia de datos

4.1. Concepto

📘 Concepto: La independencia de datos es la capacidad de modificar el esquema de un nivel sin tener que modificar el esquema del nivel superior (ni, por tanto, los programas que lo usan). Basta con ajustar la correspondencia entre ambos niveles.

Es el objetivo principal de la arquitectura de tres niveles, y la solución al problema de la dependencia física de los sistemas de ficheros (módulo 01). Hay dos tipos:

4.2. Independencia física

📘 Concepto: La independencia física es la capacidad de modificar el esquema interno sin tener que modificar el esquema conceptual ni los esquemas externos (ni las aplicaciones).

Ejemplos de cambios que no deben afectar a las aplicaciones:

  • Crear o borrar un índice para acelerar una consulta.
  • Mover una tabla a otro disco, a otro tablespace o a almacenamiento SSD.
  • Cambiar el tamaño de bloque, comprimir una tabla o particionarla por fechas.
  • Reorganizar los ficheros para recuperar espacio.

💻 Ejemplo: La consulta “empleados del departamento 30” tarda demasiado. El DBA crea el índice ix_emp_dept. La aplicación de RR. HH. no se toca: sigue ejecutando exactamente la misma consulta, pero ahora el SGBD usa el índice y responde más rápido. Esto es independencia física.

Es relativamente fácil de lograr y todos los SGBD relacionales la ofrecen en gran medida.

4.3. Independencia lógica

📘 Concepto: La independencia lógica es la capacidad de modificar el esquema conceptual sin tener que modificar los esquemas externos ni las aplicaciones que los usan (salvo las que necesiten usar los elementos nuevos o modificados).

Ejemplos:

  • Añadir una columna nueva a una tabla (por ejemplo, fecha_nacimiento en EMPLEADOS): las vistas y aplicaciones existentes no la usan, así que no se ven afectadas.
  • Añadir una tabla nueva (por ejemplo, FORMACIONES).
  • Dividir una tabla en dos y recomponerla con una vista que conserve el nombre y las columnas antiguas, para que las aplicaciones sigan funcionando.

💻 Ejemplo: Se decide que el teléfono de los empleados pase a una tabla aparte TELEFONOS_EMPLEADO (porque ahora pueden tener varios). La vista v_directorio se redefine para obtener el teléfono principal de la nueva tabla, pero conserva sus mismas columnas. La aplicación del directorio, que consulta la vista, no cambia. Esto es independencia lógica.

Es más difícil de conseguir que la física: si se borra una columna que una aplicación usa, ninguna correspondencia puede inventarse el dato.

4.4. Resumen

Tipo Se modifica No deben cambiar Se ajusta la correspondencia Dificultad
Física Esquema interno Esquema conceptual, esquemas externos, aplicaciones Conceptual/interna Menor
Lógica Esquema conceptual Esquemas externos, aplicaciones Externa/conceptual Mayor 
flowchart TB
    EXT["Esquemas externos<br/>y aplicaciones"]
    CON["Esquema conceptual"]
    INT["Esquema interno"]
    EXT ---|"correspondencia externa/conceptual<br/>→ INDEPENDENCIA LÓGICA"| CON
    CON ---|"correspondencia conceptual/interna<br/>→ INDEPENDENCIA FÍSICA"| INT

5. Esquemas y ejemplares

5.1. Definiciones

📘 Concepto:

  • El esquema de una base de datos es la descripción de su estructura: qué tablas hay, qué columnas tienen, de qué tipos, qué restricciones cumplen. Se define al diseñar la base de datos y cambia muy raramente. También se le llama intensión de la base de datos.
  • El ejemplar (o instancia, instance; también estado u ocurrencia) de una base de datos es el conjunto de datos que contiene en un momento determinado. Cambia continuamente, con cada inserción, modificación o borrado. También se le llama extensión.

Una analogía: el esquema es el formulario en blanco de matrícula (con sus casillas: nombre, DNI, ciclo…); los ejemplares son los formularios rellenos de todos los alumnos que se han matriculado hoy.

5.2. Ejemplo

Esquema (no cambia):

DEPARTAMENTOS (dept_id, nombre, localidad, presupuesto)

Ejemplar el lunes a las 9:00:

   DEPT_ID NOMBRE           LOCALIDAD    PRESUPUESTO
---------- ---------------- ------------ -----------
        10 DIRECCIÓN        Madrid            500000
        20 VENTAS           Madrid            350000
        30 INFORMÁTICA      Valencia          420000
        40 CONTABILIDAD     Sevilla           150000
        50 MARKETING        Barcelona         200000
        60 LOGÍSTICA        Zaragoza          180000
        70 INVESTIGACIÓN    Bilbao

Ejemplar el lunes a las 12:00, después de asignar presupuesto al departamento 70 y crear un departamento nuevo (datos inventados para el ejemplo):

   DEPT_ID NOMBRE           LOCALIDAD    PRESUPUESTO
---------- ---------------- ------------ -----------
        10 DIRECCIÓN        Madrid            500000
        ...
        70 INVESTIGACIÓN    Bilbao             90000
        80 CALIDAD          Valencia           60000

El esquema es el mismo; el ejemplar ha cambiado.

5.3. Ejemplar válido

⚠️ Importante: Un ejemplar es válido si cumple todas las restricciones definidas en el esquema. Una de las funciones esenciales del SGBD es garantizar que la base de datos pasa siempre de un ejemplar válido a otro ejemplar válido. Por ejemplo, si el esquema dice que nombre es único, el SGBD rechazará la inserción de un segundo departamento llamado VENTAS.

5.4. Esquemas en la arquitectura ANSI/SPARC

Cada nivel de la arquitectura tiene su esquema:

Nivel Esquema Otros nombres
Externo Esquemas externos Subesquemas, vistas de usuario
Conceptual Esquema conceptual Esquema lógico global
Interno Esquema interno Esquema físico, esquema de almacenamiento

💡 Consejo: La palabra esquema tiene además un significado específico en Oracle: el conjunto de objetos (tablas, vistas, índices…) que pertenecen a un usuario. Lo verás en el apartado 12.4. Y la palabra instancia también tiene en Oracle un significado propio (la memoria y los procesos del servidor, apartado 12.2), distinto de “ejemplar”. Por eso en este curso preferimos el término ejemplar para el contenido de la base de datos.

6. Componentes de un SGBD

6.1. Visión general

Un SGBD es un software muy complejo, formado por varios módulos que colaboran. Aunque cada producto los organiza a su manera, la estructura general es la siguiente:

flowchart TB
    subgraph USR["Usuarios y aplicaciones"]
        U1["Usuarios finales<br/>(herramientas)"]
        U2["Aplicaciones<br/>(programas)"]
        U3["DBA<br/>(DDL, DCL)"]
    end
    USR --> PC
    subgraph PC["Procesador de consultas"]
        AN["Analizador<br/>(sintáctico y semántico)"]
        OPT["Optimizador<br/>de consultas"]
        EJ["Motor de<br/>ejecución"]
        AN --> OPT --> EJ
    end
    subgraph GA["Gestor de almacenamiento"]
        GT["Gestor de transacciones<br/>(concurrencia y bloqueos)"]
        GB["Gestor de buffer<br/>(caché de bloques)"]
        GF["Gestor de ficheros"]
        GR["Gestor de<br/>recuperación"]
    end
    EJ --> GT
    EJ --> GB
    GT --> GB
    GB --> GF
    GR --> GB
    AN -.->|"consulta metadatos"| DIC
    OPT -.->|"consulta estadísticas"| DIC
    GF --> DAT[("Ficheros<br/>de datos")]
    GF --> IDX[("Índices")]
    GF --> DIC[("Diccionario<br/>de datos")]
    GT --> LOG[("Registro de<br/>transacciones<br/>(log)")]
    GR --> LOG

6.2. El procesador de consultas

Recibe las sentencias (SQL) de los usuarios y las convierte en operaciones de bajo nivel.

Componente Función
Analizador sintáctico (parser) Comprueba que la sentencia está bien escrita según la gramática del lenguaje (SELEC en lugar de SELECT es un error sintáctico)
Analizador semántico Comprueba con el diccionario que las tablas y columnas existen, que los tipos son compatibles y que el usuario tiene privilegios
Reescritura Sustituye las vistas por su definición y simplifica la consulta
Optimizador Genera varios planes de ejecución posibles (qué índices usar, en qué orden combinar las tablas, qué algoritmo de join aplicar) y elige el de menor coste estimado, usando las estadísticas del diccionario (número de filas, valores distintos, distribución…)
Motor de ejecución Ejecuta el plan elegido, pidiendo los datos al gestor de almacenamiento

📘 Concepto: El optimizador es lo que hace posible que SQL sea declarativo: tú dices qué quieres y el optimizador decide cómo obtenerlo. Oracle usa un optimizador basado en costes (Cost-Based Optimizer, CBO). Podrás ver el plan que elige con EXPLAIN PLAN (módulo 26).

6.3. El gestor de transacciones

Garantiza las propiedades ACID de las transacciones (apartado 9):

  • Control de concurrencia: coordina las transacciones simultáneas para que no interfieran (con bloqueos y, en Oracle, con versiones de los datos que permiten leer sin bloquear).
  • Gestor de bloqueos: concede, registra y libera los bloqueos sobre filas y tablas; detecta interbloqueos (deadlocks).
  • Coordina el COMMIT (confirmación) y el ROLLBACK (anulación) con el registro de transacciones.

6.4. El gestor de almacenamiento

Hace de intermediario entre los datos en disco y el resto del SGBD:

Componente Función
Gestor de ficheros Reserva espacio en disco y organiza los datos en ficheros, bloques y registros (los conceptos del módulo 01)
Gestor de buffer Mantiene en memoria una caché de bloques (buffer pool; en Oracle, database buffer cache). Decide qué bloques se quedan en memoria y cuáles se descartan (por ejemplo, con algoritmos de tipo LRU, “el menos usado recientemente”) y cuándo se escriben en disco los bloques modificados
Gestor de autorización e integridad Comprueba los privilegios y las restricciones

6.5. El diccionario de datos

Lo viste en el apartado 2.2. Desde el punto de vista de los componentes, es la fuente de información que consultan todos los demás módulos: el analizador para validar nombres y permisos, el optimizador para obtener estadísticas, el gestor de almacenamiento para saber dónde está cada tabla.

6.6. El registro de transacciones (log) y el gestor de recuperación

📘 Concepto: El registro de transacciones (transaction log; en Oracle, redo log) es un fichero en el que el SGBD anota, antes de modificar los datos en disco, todos los cambios que realizan las transacciones. Esta técnica se llama registro de escritura anticipada (Write-Ahead Logging, WAL).

Gracias al log, el gestor de recuperación puede, tras un fallo:

  • Rehacer (redo) los cambios de las transacciones confirmadas que no habían llegado a escribirse en los ficheros de datos.
  • Deshacer (undo) los cambios de las transacciones no confirmadas que sí se habían escrito.

💡 Consejo: Por eso un COMMIT es rápido aunque modifique muchos datos: el SGBD no necesita escribir en el momento todos los bloques modificados en los ficheros de datos (lo hará después, con calma); le basta con asegurarse de que el registro de transacciones está escrito en disco. Si el servidor se cae un segundo después, el log permite reconstruir los cambios.

6.7. El recorrido de una consulta

Sigamos lo que ocurre al ejecutar:

SELECT nombre, salario
FROM   empleados
WHERE  dept_id = 30;
  1. La aplicación envía el texto de la sentencia al servidor.
  2. El analizador sintáctico comprueba la gramática: correcto.
  3. El analizador semántico consulta el diccionario: la tabla EMPLEADOS existe, tiene las columnas nombre, salario y dept_id, y el usuario tiene privilegio SELECT sobre ella.
  4. El optimizador consulta las estadísticas: la tabla tiene 24 filas y existe un índice sobre dept_id. Valora dos planes: leer toda la tabla o usar el índice. Con tan pocas filas, probablemente decida leer la tabla completa (es más barato); con millones de filas, usaría el índice.
  5. El motor de ejecución ejecuta el plan y pide los bloques al gestor de buffer.
  6. El gestor de buffer busca los bloques en la memoria; si no están (fallo de caché), pide al gestor de ficheros que los lea del disco.
  7. Se filtran las filas con dept_id = 30, se extraen las columnas pedidas y se envía el resultado a la aplicación.

6.8. El recorrido de una modificación 

UPDATE empleados
SET    salario = salario * 1.05
WHERE  emp_id = 121;

COMMIT;
  1. Análisis y optimización, como en la consulta.
  2. El gestor de transacciones inicia una transacción y obtiene un bloqueo sobre la fila del empleado 121 (nadie más puede modificarla hasta que termine).
  3. Se guarda la imagen anterior del dato (para poder deshacer: en Oracle, en el undo).
  4. Se anota el cambio en el registro de transacciones (redo).
  5. Se modifica el bloque en memoria (en el buffer). Aún no se escribe en el fichero de datos.
  6. Al ejecutar COMMIT, se asegura que el registro de transacciones está escrito en disco, se libera el bloqueo y se confirma al usuario.
  7. Más tarde, un proceso del SGBD escribe el bloque modificado en el fichero de datos.

7. Lenguajes de un SGBD

7.1. Clasificación por función

Un SGBD ofrece lenguajes (o partes de un mismo lenguaje) para cada una de sus funciones. En los SGBD relacionales, todos ellos forman parte de SQL:

Sublenguaje Nombre completo Función Sentencias SQL principales Módulos
DDL Data Definition Language, lenguaje de definición de datos Crear, modificar y borrar la estructura (objetos) CREATE, ALTER, DROP, TRUNCATE, RENAME, COMMENT 19-22
DML Data Manipulation Language, lenguaje de manipulación de datos Consultar y modificar los datos SELECT, INSERT, UPDATE, DELETE, MERGE 23-30
DCL Data Control Language, lenguaje de control de datos Gestionar los permisos GRANT, REVOKE 33
TCL Transaction Control Language, lenguaje de control de transacciones Gestionar las transacciones COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION 31

⚠️ Importante: La clasificación no es idéntica en todos los libros ni en todos los fabricantes. Algunos autores incluyen SELECT en un sublenguaje aparte (DQL, Data Query Language); otros incluyen el TCL dentro del DCL. La documentación de Oracle, por ejemplo, distingue entre sentencias DDL, DML, de control de transacciones, de control de sesión y de control del sistema, e incluye GRANT y REVOKE dentro del DDL. En este curso usamos la clasificación de la tabla, que es la más extendida en la docencia.

En la arquitectura ANSI/SPARC se distinguía además entre un lenguaje para definir el esquema conceptual (DDL propiamente dicho), otro para el esquema interno (SDL, Storage Definition Language) y otro para los esquemas externos (VDL, View Definition Language). En los SGBD actuales, todos se integran en el DDL de SQL: CREATE TABLE (conceptual), CREATE INDEX o CREATE TABLESPACE (interno) y CREATE VIEW (externo).

7.2. DML procedimental y no procedimental

Tipo Cómo se expresa Unidad de trabajo Ejemplos
Procedimental (navegacional, de bajo nivel) El usuario indica qué datos quiere y cómo obtenerlos, paso a paso Un registro cada vez DML de CODASYL (FIND, GET), DL/I de IMS (GU, GN), recorrido con bucles en un programa
No procedimental (declarativo, de alto nivel) El usuario indica qué datos quiere; el SGBD decide cómo Conjuntos de registros SQL, QBE (Query By Example), QUEL

💻 Ejemplo: Obtener el nombre de los empleados del departamento 30 que cobran más de 2500 €.

Procedimental (pseudocódigo):

abrir fichero EMPLEADOS
leer primer registro
MIENTRAS no sea fin de fichero
    SI registro.dept_id = 30 Y registro.salario > 2500 ENTONCES
        mostrar registro.nombre
    FIN SI
    leer siguiente registro
FIN MIENTRAS
cerrar fichero

No procedimental (SQL):

SELECT nombre
FROM   empleados
WHERE  dept_id = 30
AND    salario > 2500;

En la versión SQL no hay bucles, ni ficheros que abrir, ni decisiones sobre el orden de lectura: el optimizador decide si recorre la tabla o usa un índice.

7.3. Lenguajes anfitriones (huésped) y formas de acceso

SQL es muy potente para manejar datos, pero no sirve para construir una aplicación completa (interfaz de usuario, lógica de negocio, comunicaciones). Por eso las sentencias SQL se suelen usar desde otro lenguaje de programación, al que se llama lenguaje anfitrión (host language); en muchos textos en español también se le llama, por traducción, lenguaje huésped.

Forma de acceso Descripción Ejemplos
Interactiva El usuario escribe SQL directamente en una herramienta y ve el resultado SQL*Plus, SQLcl, SQL Developer, DBeaver
SQL embebido Las sentencias SQL se escriben dentro del código del programa y un precompilador las traduce a llamadas Pro*C/C++ y Pro*COBOL de Oracle, SQLJ
API de llamadas El programa usa una biblioteca para enviar SQL al SGBD y recibir los resultados JDBC (Java), ODBC, ADO.NET (C#), PDO (PHP), python-oracledb (Python), node-oracledb (JavaScript)
ORM Una biblioteca traduce automáticamente objetos del lenguaje a tablas y genera el SQL Hibernate/JPA, Entity Framework, Doctrine, SQLAlchemy
Lenguaje procedimental del SGBD Lenguaje que se ejecuta dentro del servidor y amplía SQL con variables, bucles y condiciones PL/SQL (Oracle), T-SQL (SQL Server), PL/pgSQL (PostgreSQL)

💡 Consejo: Este curso trata solo SQL. La programación dentro de Oracle con PL/SQL (bloques, procedimientos, funciones, cursores y triggers) se estudia en el Curso de Oracle PL/SQL.

8. Usuarios y roles

Alrededor de una base de datos trabajan personas con responsabilidades muy distintas. La clasificación clásica (Elmasri y Navathe, de Miguel y Piattini) distingue los siguientes perfiles.

8.1. Administradores

Rol Responsabilidades
Administrador de datos (Data Administrator, DA) Responsable organizativo de los datos: decide qué datos se guardan, define las políticas de uso, calidad, privacidad y conservación. Perfil más de gestión que técnico
Administrador de la base de datos (Database Administrator, DBA) Responsable técnico: instala y configura el SGBD, crea las estructuras de almacenamiento, gestiona usuarios y privilegios, planifica las copias y la recuperación, vigila y ajusta el rendimiento, aplica parches y actualizaciones

En organizaciones pequeñas ambos papeles los asume la misma persona; en las grandes hay equipos de DBA especializados (de sistemas, de desarrollo, de seguridad…).

8.2. Diseñadores

Rol Responsabilidades
Diseñador conceptual y lógico Analiza los requisitos con los usuarios, elabora el esquema conceptual (E/R) y lo transforma en el esquema lógico (relacional normalizado). Es el protagonista de los bloques 2 y 3 del curso
Diseñador físico Decide cómo implementar el esquema lógico en un SGBD concreto: índices, particiones, almacenamiento, desnormalizaciones justificadas. Suele ser un DBA

8.3. Programadores de aplicaciones

Desarrollan los programas que usan la base de datos: escriben las consultas y modificaciones (SQL embebido, API, ORM) e implementan las transacciones. También se les llama desarrolladores o ingenieros de software.

8.4. Usuarios finales

Tipo Descripción Ejemplo
Paramétricos (ingenuos, naive) Usan la base de datos a través de aplicaciones con pantallas y opciones predefinidas, sin saber nada de SQL. Son la gran mayoría Cajero de un banco, dependienta que registra ventas, cliente de una tienda online
Ocasionales (casual) Acceden de vez en cuando, con necesidades de información diferentes cada vez, mediante herramientas de consulta o informes Directivo que consulta un cuadro de mando
Sofisticados Conocen el SGBD y su lenguaje de consulta, y formulan sus propias consultas complejas Analista de datos, ingeniero que escribe consultas SQL
Autónomos (standalone) Mantienen bases de datos personales con aplicaciones sencillas Autónomo que gestiona su agenda de clientes en una aplicación de escritorio

8.5. Otros perfiles

  • Desarrolladores de herramientas: crean el propio SGBD o herramientas auxiliares (modelado, monitorización, migración).
  • Operadores y personal de mantenimiento: se ocupan del hardware y del funcionamiento diario de los sistemas.

8.6. Relación con la arquitectura de tres niveles

Nivel ANSI/SPARC Perfiles que trabajan en él
Externo Usuarios finales, programadores de aplicaciones
Conceptual Diseñadores conceptuales y lógicos, DBA, administrador de datos
Interno DBA, diseñadores físicos

9. Transacciones y propiedades ACID

9.1. ¿Qué es una transacción?

📘 Concepto: Una transacción es una secuencia de operaciones sobre la base de datos que forman una unidad lógica de trabajo: o se ejecutan todas con éxito y sus cambios se hacen permanentes, o no se ejecuta ninguna y la base de datos queda como estaba.

El ejemplo clásico es una transferencia bancaria de 100 € de la cuenta A a la cuenta B. Desde el punto de vista del negocio es una sola operación, pero para la base de datos son al menos dos:

-- Ejemplo ilustrativo con una tabla cuentas (numero, titular, saldo)
-- Transferencia de 100 € de la cuenta 'ES01' a la cuenta 'ES02'
UPDATE cuentas SET saldo = saldo - 100 WHERE numero = 'ES01';   -- 1. retirar de A
UPDATE cuentas SET saldo = saldo + 100 WHERE numero = 'ES02';   -- 2. ingresar en B
COMMIT;                                                          -- 3. confirmar

Si el sistema falla entre el paso 1 y el paso 2, sin transacciones se habrían “evaporado” 100 €: retirados de A, pero nunca ingresados en B.

9.2. Las propiedades ACID

Para que las transacciones sean fiables, el SGBD debe garantizar cuatro propiedades, conocidas por sus iniciales en inglés: ACID.

Propiedad Significado En la transferencia bancaria Componente del SGBD responsable
Atomicidad (Atomicity) La transacción es indivisible: se ejecuta entera o no se ejecuta. Si algo falla, se deshacen todos sus cambios O se hacen los dos UPDATE, o ninguno. Si falla el segundo, se deshace el primero Gestor de transacciones y de recuperación (undo)
Consistencia (Consistency) La transacción lleva la base de datos de un estado válido a otro estado válido, respetando todas las restricciones La suma de los saldos de A y B es la misma antes y después; ningún saldo queda negativo si hay una restricción que lo impide Comprobación de restricciones de integridad (y la lógica correcta de la aplicación)
Aislamiento (Isolation) Las transacciones concurrentes no interfieren entre sí: cada una se comporta como si se ejecutara sola Si mientras tanto alguien consulta el saldo total del banco, no ve un estado intermedio con 100 € de menos Control de concurrencia (bloqueos, versiones)
Durabilidad (Durability) Una vez confirmada, los cambios de la transacción son permanentes, aunque el sistema falle justo después Tras el COMMIT, aunque se vaya la luz, la transferencia no se pierde Registro de transacciones (redo log) y gestor de recuperación

💡 Consejo: Una forma de recordar quién garantiza qué: la A y la D las garantiza el log (deshacer y rehacer); la I, el control de concurrencia; la C es responsabilidad compartida entre el SGBD (restricciones) y el programador (que la transacción tenga sentido: no sirve de nada la atomicidad si el programa resta 100 € de A y suma 10 € a B).

9.3. Estados de una transacción 

stateDiagram-v2
    [*] --> Activa: comienza
    Activa --> ParcialmenteConfirmada: última operación ejecutada
    Activa --> Fallida: error
    ParcialmenteConfirmada --> Confirmada: COMMIT completado
    ParcialmenteConfirmada --> Fallida: error al confirmar
    Fallida --> Abortada: ROLLBACK (se deshacen los cambios)
    Confirmada --> [*]
    Abortada --> [*]
Estado Descripción
Activa Se están ejecutando sus operaciones
Parcialmente confirmada Se ha ejecutado la última operación, pero aún no se ha garantizado que los cambios sean permanentes
Confirmada (committed) Los cambios son permanentes
Fallida Se ha producido un error y no puede continuar
Abortada (rolled back) Se han deshecho todos sus cambios; la base de datos está como antes de empezar

9.4. Transacciones en Oracle: una primera idea

En Oracle, una transacción empieza automáticamente con la primera sentencia DML (INSERT, UPDATE, DELETE, MERGE) y termina con:

  • COMMIT: confirma los cambios.
  • ROLLBACK: los deshace.
  • Una sentencia DDL (CREATE, ALTER, DROP…), que hace un COMMIT implícito.
  • El fin de la sesión (normal: se confirma, en las herramientas habituales; anómala: se deshace).

⚠️ Importante: Mientras no hagas COMMIT, los demás usuarios no ven tus cambios, y tú puedes deshacerlos con ROLLBACK. Esto es lo que te permitirá experimentar con UPDATE y DELETE sobre el esquema EMPRESA sin miedo a estropearlo. Las transacciones, los bloqueos y los niveles de aislamiento se estudian a fondo en el módulo 35.

10. Arquitecturas de los sistemas de bases de datos

10.1. Arquitectura centralizada

En los años sesenta y setenta, todo (datos, SGBD, aplicaciones e interfaz) se ejecutaba en un único ordenador central (mainframe). Los usuarios se conectaban mediante terminales “tontos” que solo mostraban texto y enviaban lo que se tecleaba.

  • Ventajas: administración sencilla, seguridad centralizada, coherencia.
  • Inconvenientes: el ordenador central es un cuello de botella y un punto único de fallo; caro de ampliar.

10.2. Arquitectura cliente/servidor

Con la llegada de los ordenadores personales y las redes locales (años ochenta y noventa), el trabajo se reparte entre:

  • El servidor: ejecuta el SGBD y guarda los datos.
  • Los clientes: ejecutan las aplicaciones y la interfaz de usuario, y envían peticiones (SQL) al servidor por la red.
flowchart LR
    C1["Cliente 1<br/>(aplicación)"] -->|"SQL"| S["Servidor<br/>SGBD"]
    C2["Cliente 2<br/>(aplicación)"] -->|"SQL"| S
    C3["Cliente 3<br/>(SQL Developer)"] -->|"SQL"| S
    S -->|"resultados"| C1
    S -->|"resultados"| C2
    S -->|"resultados"| C3
    S --- BD[("Base de<br/>datos")]

10.3. Arquitectura de dos capas

Es la forma más sencilla de cliente/servidor: la aplicación cliente contiene la interfaz y la lógica de negocio, y se conecta directamente al servidor de base de datos.

  • Ventajas: sencilla de desarrollar.
  • Inconvenientes: hay que instalar y actualizar la aplicación en cada cliente; cada cliente abre su conexión con la base de datos (escala mal con miles de usuarios); la lógica de negocio está repartida por todos los clientes; las credenciales de la base de datos están en cada equipo.

Ejemplo: una aplicación de escritorio de gestión de un pequeño comercio que se conecta directamente a un servidor MySQL de la tienda.

10.4. Arquitectura de tres capas (y n capas)

Se añade una capa intermedia entre el cliente y la base de datos:

Capa Función Ejemplos
Presentación (cliente) Interfaz de usuario Navegador web, aplicación móvil
Lógica de negocio (aplicación, middleware) Reglas del negocio, validaciones, orquestación; es la única que habla con la BD Servidor de aplicaciones con Java, C#, PHP, Python, Node.js; servicios REST
Datos Almacenamiento y gestión de los datos Servidor Oracle, PostgreSQL… 
flowchart LR
    subgraph P["Capa de presentación"]
        N["Navegador"]
        M["App móvil"]
    end
    subgraph L["Capa de lógica de negocio"]
        AS["Servidor de aplicaciones<br/>(API REST)"]
    end
    subgraph D["Capa de datos"]
        DB["SGBD"] --- BD[("BD")]
    end
    N -->|"HTTPS"| AS
    M -->|"HTTPS"| AS
    AS -->|"SQL<br/>(pool de conexiones)"| DB
  • Ventajas: los clientes no necesitan instalar nada (basta un navegador); la lógica está centralizada; la capa intermedia reutiliza un conjunto de conexiones (connection pool) para miles de usuarios; mayor seguridad (la base de datos no está expuesta a internet); cada capa escala por separado.
  • Inconvenientes: mayor complejidad de desarrollo y despliegue.

Cuando la capa intermedia se divide a su vez en varios servicios (autenticación, catálogo, pagos…), se habla de arquitectura de n capas o de microservicios.

💡 Consejo: La inmensa mayoría de las aplicaciones web actuales siguen una arquitectura de tres capas o más. Si estudias DAW, la verás en la práctica: el navegador (HTML, CSS, JavaScript) es la presentación, tu aplicación en PHP, Java o Node.js es la lógica, y la base de datos que diseñas en este curso es la capa de datos.

10.5. Arquitecturas centralizadas frente a distribuidas

Ya viste en el módulo 02 qué es una base de datos distribuida. Desde el punto de vista de la arquitectura del sistema:

Aspecto Centralizada Distribuida
Ubicación de los datos Un solo sitio (servidor o clúster local) Varios nodos en distintas ubicaciones
Administración Más sencilla Más compleja
Disponibilidad Depende de un único sitio Mayor: si un nodo falla, los demás siguen
Rendimiento Bueno en local; peor para usuarios lejanos Datos cerca de quien los usa; las consultas que cruzan nodos son costosas
Escalabilidad Vertical (servidor más grande) Horizontal (más nodos)
Transacciones Sencillas Requieren protocolos especiales, como el commit en dos fases (2PC)
Ejemplo La base de datos de un instituto en su servidor Una base de datos bancaria con nodos en varios países

Entre ambos extremos existen soluciones intermedias muy utilizadas:

  • Replicación: una base de datos principal y una o varias copias sincronizadas (para lectura o para tomar el relevo si la principal falla). En Oracle: Data Guard y Active Data Guard.
  • Clústeres: varios servidores que trabajan sobre la misma base de datos, compartiendo el almacenamiento (arquitectura shared-disk). En Oracle: RAC (Real Application Clusters).
  • Fragmentación (sharding): cada servidor guarda una parte de los datos (arquitectura shared-nothing). En Oracle: Globally Distributed Database.

11. SGBD del mercado

11.1. Tabla comparativa

SGBD Fabricante / comunidad Licencia Modelo Uso típico Opción gratuita
Oracle AI Database Oracle Propietaria Relacional, multimodelo (JSON, grafos, espacial, vectorial) Grandes empresas, banca, administración, ERP, sistemas críticos Edición Free; servicio FreeSQL; capa gratuita de Autonomous Database
Microsoft SQL Server Microsoft Propietaria Relacional (con JSON, grafos, vectores) Empresas con ecosistema Microsoft, aplicaciones .NET, BI Ediciones Express y Developer
MySQL Oracle (comunidad) GPL (Community) + comercial (Enterprise) Relacional Aplicaciones web, CMS (WordPress, Drupal), startups Community Edition
MariaDB MariaDB Foundation y MariaDB plc GPL Relacional Alternativa libre a MySQL; distribuciones Linux Sí (libre)
PostgreSQL PostgreSQL Global Development Group Licencia PostgreSQL (permisiva) Objeto-relacional, muy extensible (JSON, PostGIS, pgvector) Aplicaciones web y empresariales, datos geográficos, alternativa libre a Oracle Sí (libre)
SQLite D. Richard Hipp y colaboradores Dominio público Relacional embebido Móviles, navegadores, aplicaciones de escritorio, IoT, pruebas Sí
IBM Db2 IBM Propietaria Relacional Mainframes, banca, grandes corporaciones Edición Community
MongoDB MongoDB Inc. SSPL (Community) + comercial Documental (NoSQL) Aplicaciones web y móviles, catálogos, contenidos Community Server; capa gratuita en MongoDB Atlas
Redis Redis Ltd. Ha cambiado varias veces (consulta la vigente); existe el fork libre Valkey Clave-valor en memoria Caché, sesiones, colas, tiempo real Sí
Apache Cassandra Apache Software Foundation Apache 2.0 Familias de columnas (NoSQL) Escrituras masivas, IoT, mensajería Sí (libre)
Neo4j Neo4j Inc. GPL (Community) + comercial (Enterprise) Grafos Redes sociales, fraude, recomendaciones Community Edition

11.2. ¿Por qué Oracle en este curso?

  • Es uno de los SGBD más usados en la empresa y figura de forma estable entre los primeros de las clasificaciones de popularidad (como DB-Engines).
  • Implementa un SQL muy completo, con extensiones potentes (funciones analíticas, consultas jerárquicas, PIVOT, MERGE…).
  • Es el SGBD tradicional de referencia en muchos ciclos formativos y universidades españolas.
  • Ofrece una edición gratuita (Free) completa para aprender, que se instala fácilmente con Docker, y servicios en línea gratuitos.
  • Lo que aprendas es transferible: el SQL estándar que usarás funciona, con pocas diferencias, en PostgreSQL, SQL Server o MySQL.

12. Oracle Database: arquitectura conceptual

En este apartado conocerás, sin escribir todavía SQL, los conceptos de Oracle que necesitarás para entender la instalación (módulo 22) y la administración de usuarios (módulo 37).

12.1. Servidor Oracle = instancia + base de datos

📘 Concepto: En Oracle se distingue con precisión entre:

  • Base de datos (database): el conjunto de ficheros físicos en disco que contienen los datos y la información necesaria para gestionarlos.
  • Instancia (instance): el conjunto de estructuras de memoria y procesos en segundo plano que gestionan esa base de datos mientras está en funcionamiento.

Un servidor de base de datos Oracle está formado por, al menos, una instancia y una base de datos.

La analogía: la base de datos es el almacén con la mercancía (permanente); la instancia es el equipo de trabajadores y las carretillas que mueven la mercancía mientras el almacén está abierto. Cuando se “para” la base de datos, la instancia desaparece (se libera la memoria y terminan los procesos), pero los ficheros siguen en el disco.

💡 Consejo: Normalmente cada base de datos tiene una instancia. En una configuración RAC (Real Application Clusters), varias instancias, en servidores distintos, abren a la vez la misma base de datos, lo que aporta escalabilidad y alta disponibilidad.

12.2. La instancia: memoria y procesos 

flowchart TB
    subgraph INST["INSTANCIA (memoria y procesos)"]
        subgraph SGA["SGA (System Global Area), compartida"]
            BC["Database buffer cache<br/>(bloques de datos)"]
            SP["Shared pool<br/>(SQL analizado, diccionario)"]
            RB["Redo log buffer<br/>(cambios pendientes de log)"]
        end
        PGA["PGA (Program Global Area)<br/>memoria privada de cada proceso"]
        DBW["DBWn<br/>(escribe bloques)"]
        LGW["LGWR<br/>(escribe el redo log)"]
        CKP["CKPT<br/>(puntos de control)"]
        SMO["SMON / PMON<br/>(recuperación y limpieza)"]
        ARC["ARCn<br/>(archiva el redo log)"]
    end
    subgraph BDF["BASE DE DATOS (ficheros)"]
        DF[("Ficheros de datos")]
        CF[("Ficheros de control")]
        RL[("Ficheros de redo log")]
    end
    ARL[("Redo logs<br/>archivados")]
    DBW --> DF
    LGW --> RL
    CKP --> CF
    ARC --> ARL
Elemento Tipo Función
SGA (System Global Area) Memoria compartida Zona de memoria común a todos los procesos de la instancia
Database buffer cache Parte de la SGA Caché de los bloques de datos leídos del disco (el gestor de buffer del apartado 6.4)
Shared pool Parte de la SGA Guarda las sentencias SQL ya analizadas y sus planes (para no repetir el análisis) y la caché del diccionario
Redo log buffer Parte de la SGA Guarda temporalmente los cambios antes de escribirlos en el redo log
PGA (Program Global Area) Memoria privada Memoria de cada proceso servidor (ordenaciones, variables de sesión)
DBWn (Database Writer) Proceso Escribe en los ficheros de datos los bloques modificados de la buffer cache
LGWR (Log Writer) Proceso Escribe en los ficheros de redo log el contenido del redo log buffer; en cada COMMIT se asegura de que el redo de la transacción está en disco
CKPT (Checkpoint) Proceso Registra los puntos de control en los ficheros de control y de datos
SMON (System Monitor) Proceso Realiza la recuperación al arrancar tras una caída
PMON (Process Monitor) Proceso Limpia los recursos de los procesos de usuario que terminan de forma anómala
ARCn (Archiver) Proceso Copia los redo logs llenos a ficheros archivados (necesarios para la recuperación completa)

Además, por cada conexión de un usuario se crea (o se asigna) un proceso servidor que ejecuta sus sentencias SQL.

12.3. La base de datos: estructura física y lógica

Estructura física (ficheros en disco):

Fichero Contenido
Ficheros de datos (datafiles, .dbf) Los datos de las tablas, índices y demás objetos
Ficheros de control (control files) Información sobre la estructura física de la BD: nombres y ubicación de los ficheros, estado, puntos de control. Son imprescindibles para abrir la base de datos, por lo que se guardan varias copias
Ficheros de redo log (online redo log files) El registro de transacciones del apartado 6.6, organizado en grupos que se usan de forma circular
Redo logs archivados Copias de los redo logs llenos, cuando la BD funciona en modo ARCHIVELOG
Fichero de parámetros (spfile) Configuración de la instancia (tamaño de la memoria, etc.)

Estructura lógica (cómo organiza Oracle el espacio):

flowchart LR
    TS["Tablespace<br/>(p. ej. USERS)"] -->|"se compone de"| SEG["Segmentos<br/>(una tabla, un índice)"]
    SEG -->|"se componen de"| EXT["Extensiones<br/>(extents)"]
    EXT -->|"se componen de"| BLK["Bloques de datos<br/>(p. ej. 8 KB)"]
    TS -.->|"se almacena en uno<br/>o varios"| DF[("Ficheros<br/>de datos")]
Estructura Descripción
Tablespace Unidad lógica de almacenamiento que agrupa objetos relacionados. Cada tablespace se guarda en uno o varios ficheros de datos. Algunos habituales: SYSTEM y SYSAUX (diccionario y componentes internos), UNDO (imágenes anteriores para deshacer), TEMP (operaciones temporales), USERS (datos de usuario)
Segmento El espacio que ocupa un objeto concreto (la tabla EMPLEADOS, el índice de su clave primaria)
Extensión (extent) Conjunto de bloques contiguos que se asigna a un segmento cuando necesita crecer
Bloque de datos La unidad mínima de lectura y escritura de Oracle (8 KB por defecto). Es el “bloque” del módulo 01

📘 Concepto: Esta separación entre estructura lógica (tablespaces, segmentos) y física (ficheros) es un ejemplo práctico de la independencia física: el DBA puede añadir ficheros a un tablespace o moverlos de disco sin que las tablas ni las aplicaciones se enteren.

12.4. Usuarios y esquemas

📘 Concepto: En Oracle:

  • Un usuario es una cuenta con la que es posible conectarse a la base de datos (si tiene el privilegio necesario) y a la que se asignan privilegios.
  • Un esquema (schema) es el conjunto de objetos (tablas, vistas, índices, secuencias…) que pertenecen a un usuario. El esquema tiene el mismo nombre que el usuario y se crea automáticamente con él.

Por eso, en Oracle, “el esquema EMPRESA” significa “las tablas del esquema EMPRESA que pertenecen al usuario con el que las has creado”. Si te conectas como el usuario ALUMNO01 y ejecutas los scripts del curso, las nueve tablas se crean en el esquema ALUMNO01. Otro usuario, con los privilegios adecuados, se referiría a ellas con el prefijo del esquema: alumno01.empleados.

flowchart TB
    subgraph PDB["Base de datos (PDB)"]
        subgraph S1["Esquema ALUMNO01 (usuario ALUMNO01)"]
            T1["EMPLEADOS"]
            T2["DEPARTAMENTOS"]
            T3["... (9 tablas)"]
        end
        subgraph S2["Esquema ALUMNO02 (usuario ALUMNO02)"]
            T4["EMPLEADOS"]
            T5["..."]
        end
        subgraph S3["Esquema SYS"]
            T6["Diccionario de datos"]
        end
    end

Observa que dos usuarios pueden tener cada uno su propia tabla EMPLEADOS sin conflicto: son objetos distintos, en esquemas distintos.

Usuarios especiales que crea Oracle al instalarse:

Usuario Función
SYS Propietario del diccionario de datos. Tiene todos los privilegios. Solo se usa para tareas de administración críticas
SYSTEM Usuario administrativo para tareas habituales de administración
Otros usuarios internos Propietarios de componentes concretos (normalmente bloqueados)

⚠️ Importante: Nunca crees tus tablas de trabajo conectado como SYS o SYSTEM. Crea un usuario propio (lo harás en el módulo 22) y trabaja con él. Un error como DROP sobre un objeto de SYS puede dejar inservible la base de datos.

12.5. Arquitectura multitenant: CDB y PDB

Desde Oracle 12c (2013), Oracle ofrece la arquitectura multitenant (multiinquilino), y desde Oracle 21c es la única admitida: ya no se pueden crear bases de datos con la arquitectura clásica (non-CDB).

📘 Concepto:

  • Una CDB (Container Database, base de datos contenedora) es una base de datos que contiene a otras.
  • Una PDB (Pluggable Database, base de datos conectable) es una base de datos completa e independiente (con sus usuarios, esquemas, tablas y datos) que vive dentro de una CDB. Para una aplicación o un usuario, una PDB es indistinguible de una base de datos tradicional.

Una CDB contiene:

Contenedor Descripción
CDB$ROOT (la raíz) Guarda los metadatos y objetos comunes de Oracle y los usuarios comunes. No se usa para datos de aplicaciones
PDB$SEED (la semilla) Plantilla de solo lectura para crear nuevas PDB rápidamente
PDB de usuario Las bases de datos de las aplicaciones. Puede haber varias en la misma CDB 
flowchart TB
    subgraph SRV["Servidor"]
        subgraph INST2["Instancia (una sola SGA y procesos)"]
            I2["Memoria y procesos<br/>compartidos por todas las PDB"]
        end
        subgraph CDB["CDB (base de datos contenedora)"]
            ROOT["CDB$ROOT<br/>(raíz: diccionario común,<br/>usuarios comunes)"]
            SEED["PDB$SEED<br/>(plantilla)"]
            PDB1["PDB VENTAS<br/>(usuarios y esquemas<br/>de la app de ventas)"]
            PDB2["PDB RRHH<br/>(usuarios y esquemas<br/>de la app de RR. HH.)"]
            PDB3["FREEPDB1<br/>(en Oracle Free)"]
        end
    end
    INST2 --- CDB

Ventajas de la arquitectura multitenant:

  • Consolidación: muchas bases de datos comparten una sola instancia (memoria y procesos), lo que ahorra recursos.
  • Administración simplificada: se aplica un parche o se hace una copia de seguridad una vez para toda la CDB.
  • Aislamiento: cada PDB tiene sus propios usuarios y datos; un usuario de una PDB no ve las demás.
  • Portabilidad: una PDB se puede desconectar de una CDB y conectar a otra (de ahí pluggable), o clonar en segundos para crear un entorno de pruebas.

Tipos de usuarios en una arquitectura multitenant:

Tipo Dónde existe Nombre
Usuario común En la raíz y en todas las PDB Debe empezar por C## (por ejemplo, C##ADMIN), salvo los de Oracle (SYS, SYSTEM)
Usuario local Solo en una PDB concreta Nombre normal (por ejemplo, ALUMNO01)

💡 Consejo: Cuando instales Oracle AI Database 26ai Free, tendrás una CDB llamada FREE con una PDB ya creada llamada FREEPDB1. Trabajarás siempre conectado a FREEPDB1, con un usuario local. Un error muy común de los principiantes es conectarse a la raíz (CDB$ROOT) e intentar crear allí un usuario normal: Oracle lo rechaza porque en la raíz solo se pueden crear usuarios comunes (C##...). Lo verás paso a paso en el módulo 22.

12.6. Ediciones de Oracle Database

Edición Destinatarios Características principales
Enterprise Edition (EE) Grandes organizaciones y sistemas críticos Todas las funciones, y opciones de pago adicionales (RAC, particionamiento, In-Memory, Active Data Guard, multitenant con más de 3 PDB de usuario…)
Standard Edition 2 (SE2) Empresas medianas Funciones básicas completas, con límites de hardware (servidores de hasta 2 zócalos de CPU y un número limitado de hilos por base de datos) y hasta 3 PDB de usuario por CDB
Free Aprendizaje, desarrollo, pruebas y uso libre Gratuita, con casi todas las funciones de la Enterprise Edition, pero limitada en recursos: hasta 2 hilos de CPU, 2 GB de RAM y 12 GB de datos de usuario. Sustituyó a la antigua Express Edition (XE)

📘 Concepto: La edición Free es la que usarás en el curso. Sus límites no suponen ningún problema para aprender: el esquema EMPRESA ocupa una fracción minúscula de los 12 GB permitidos.

Oracle también se ofrece en la nube como servicio: Oracle Autonomous Database, Oracle Base Database Service, Exadata Database Service, y servicios en las nubes de otros proveedores (Oracle Database@Azure, @AWS, @Google Cloud).

12.7. Versiones actuales

Desde 2018, Oracle numera las versiones según el año y distingue dos tipos:

  • Versiones de soporte a largo plazo (Long Term Release): pensadas para producción, con muchos años de soporte.
  • Versiones de innovación (Innovation Release): introducen novedades entre dos versiones de largo plazo, con un periodo de soporte más corto.
Versión Año Tipo Situación (octubre de 2026)
19c 2019 Largo plazo Muy extendida en producción. Oracle ha anunciado soporte Premier hasta el 31/12/2029 y extendido hasta el 31/12/2032
21c 2020 Innovación Primera versión solo multitenant. Su soporte termina en 2027 (sin soporte extendido)
23ai 2024 Largo plazo Llamada inicialmente 23c; se renombró a 23ai en 2024 por sus funciones de IA (AI Vector Search). Sustituida por 26ai
AI Database 26ai 2025 Largo plazo Versión actual. Anunciada en octubre de 2025 como sustituta de 23ai; se pasa de 23ai a 26ai aplicando una actualización (release update), sin una migración completa

⚠️ Importante: Las fechas de fin de soporte dependen de la política de Oracle, que se revisa con el tiempo. Para planificar un sistema real, consulta siempre la nota oficial de soporte de versiones de Oracle (Release Schedule of Current Database Releases).

💡 Consejo: En la práctica encontrarás en las empresas sobre todo 19c y, cada vez más, 23ai/26ai. Todo el SQL del curso funciona en 19c, 21c y 26ai; cuando algo solo existe desde 23ai (por ejemplo, el tipo BOOLEAN o DROP TABLE IF EXISTS), se indica expresamente.

13. Ejercicios

Ejercicios resueltos

Ejercicio 1: Niveles ANSI/SPARC

Indica a qué nivel de la arquitectura ANSI/SPARC (externo, conceptual o interno) pertenece cada elemento:

a) La tabla PRODUCTOS tiene una columna precio de tipo NUMBER(8,2) que no puede ser negativa. b) El departamento de marketing ve una lista de productos con su nombre y precio, pero no el stock. c) La tabla PEDIDOS se almacena en el tablespace DATOS_VENTAS, en dos ficheros de datos en discos SSD. d) Existe un índice B-tree sobre CLIENTES(nif). e) Un cliente está atendido como máximo por un comercial. f) La aplicación de los comerciales muestra, para cada cliente, el número total de pedidos que ha hecho.

Ver solución
Elemento Nivel Justificación
a) Tipo y restricción de precio Conceptual Describe los datos y sus restricciones para toda la organización
b) Lista de marketing sin stock Externo Es una vista parcial para un grupo de usuarios
c) Tablespace y ficheros Interno Describe el almacenamiento físico
d) Índice B-tree Interno Es una estructura de acceso físico; no cambia qué datos hay
e) Un comercial por cliente Conceptual Es una restricción del negocio sobre las relaciones entre datos
f) Total de pedidos por cliente Externo Es un dato derivado que solo existe en la vista de esa aplicación (se calcula a partir del nivel conceptual)

Ejercicio 2: Independencia de datos

Para cada cambio, indica si es un cambio del esquema interno o del conceptual, qué tipo de independencia permite que las aplicaciones no se vean afectadas y si, en efecto, las aplicaciones podrían seguir funcionando sin cambios:

a) Se crea un índice sobre PEDIDOS(fecha_pedido). b) Se añade a CLIENTES la columna fecha_nacimiento. c) Se borra de EMPLEADOS la columna telefono, que usa la aplicación del directorio. d) Se particiona la tabla LINEAS_PEDIDO por años. e) Se divide la tabla CLIENTES en CLIENTES (datos básicos) y CLIENTES_CONTACTO (email y teléfono), y se crea una vista con el nombre y las columnas originales.

Ver solución
Cambio Esquema afectado Independencia ¿Las aplicaciones siguen igual?
a) Índice Interno Física Sí: las consultas son las mismas, solo cambia su velocidad
b) Nueva columna Conceptual Lógica Sí, siempre que las aplicaciones nombren las columnas que usan (por ejemplo, un INSERT sin lista de columnas sí fallaría)
c) Borrar columna usada Conceptual Lógica No: la aplicación del directorio necesita un dato que ya no existe. La independencia lógica tiene límites
d) Particionar Interno Física Sí: las particiones son transparentes para las consultas
e) Dividir la tabla con vista Conceptual Lógica Sí para las consultas: la vista conserva la estructura antigua. Las modificaciones a través de la vista pueden requerir trabajo adicional

Observa la advertencia del apartado b): usar INSERT INTO clientes VALUES (...) sin indicar las columnas hace que el programa dependa del número y orden exacto de columnas, y rompe la independencia lógica. Es una mala práctica que evitarás en el módulo 34.

Ejercicio 3: Esquema o ejemplar

Indica si cada afirmación se refiere al esquema o al ejemplar de la base de datos EMPRESA:

a) Hay 24 empleados. b) La tabla LINEAS_PEDIDO tiene una clave primaria formada por pedido_id y num_linea. c) El departamento 70 no tiene empleados. d) El estado de un pedido solo puede ser PENDIENTE, ENVIADO, ENTREGADO o CANCELADO. e) El pedido 5014 no tiene empleado asignado. f) La columna email de EMPLEADOS es obligatoria.

Ver solución
  • a) Ejemplar: es el contenido actual; mañana puede haber 25.
  • b) Esquema: es parte de la definición de la tabla.
  • c) Ejemplar: es una situación de los datos actuales (el esquema permite que tenga empleados).
  • d) Esquema: es una restricción (ck_ped_estado).
  • e) Ejemplar: es un dato concreto (que el esquema permite porque empleado_id admite nulos).
  • f) Esquema: es una restricción NOT NULL.

Ejercicio 4: Componentes del SGBD

Ordena los pasos que sigue el SGBD para ejecutar SELECT nombre FROM clientes WHERE ciudad = 'Valencia'; e indica qué componente realiza cada uno: (1) leer del disco los bloques que no están en memoria, (2) comprobar que la tabla CLIENTES existe y que el usuario tiene permiso, (3) elegir entre recorrer la tabla o usar un índice sobre ciudad, (4) comprobar que la sentencia está bien escrita, (5) buscar los bloques necesarios en la caché de memoria, (6) ejecutar el plan y filtrar las filas.

Ver solución
Orden Paso Componente
1.º (4) Comprobar la sintaxis Analizador sintáctico (procesador de consultas)
2.º (2) Comprobar tabla y permisos Analizador semántico, consultando el diccionario de datos
3.º (3) Elegir el plan Optimizador de consultas, con las estadísticas del diccionario
4.º (6) Ejecutar el plan Motor de ejecución
5.º (5) Buscar bloques en memoria Gestor de buffer (gestor de almacenamiento)
6.º (1) Leer bloques del disco Gestor de ficheros (solo si hay fallos de caché)

Los pasos 4.º, 5.º y 6.º se entrelazan: el motor de ejecución va pidiendo bloques mientras filtra filas.

Ejercicio 5: Clasificación de sentencias

Clasifica cada sentencia como DDL, DML, DCL o TCL:

a) CREATE TABLE proyectos (...); b) SELECT * FROM proyectos; c) GRANT SELECT ON proyectos TO alumno02; d) ROLLBACK; e) ALTER TABLE proyectos ADD (responsable NUMBER(6)); f) DELETE FROM asignaciones WHERE proyecto_id = 5; g) REVOKE SELECT ON proyectos FROM alumno02; h) TRUNCATE TABLE asignaciones; i) SAVEPOINT antes_de_borrar; j) MERGE INTO productos ...

Ver solución
Sentencia Tipo Comentario
a) CREATE TABLE DDL Crea un objeto
b) SELECT DML Algunos autores lo llaman DQL
c) GRANT DCL Concede un privilegio (Oracle lo clasifica como DDL en su documentación)
d) ROLLBACK TCL Deshace la transacción
e) ALTER TABLE DDL Modifica la estructura
f) DELETE DML Borra filas (se puede deshacer con ROLLBACK)
g) REVOKE DCL Retira un privilegio
h) TRUNCATE DDL Aunque vacíe la tabla como un DELETE, es DDL: hace COMMIT implícito y no se puede deshacer con ROLLBACK
i) SAVEPOINT TCL Marca un punto intermedio de la transacción
j) MERGE DML Inserta o modifica según exista o no la fila

La trampa está en TRUNCATE: es un error frecuente clasificarlo como DML. Lo estudiarás en el módulo 25.

Ejercicio 6: Propiedades ACID

Indica qué propiedad ACID se ve comprometida en cada situación (y que el SGBD debe impedir):

a) Se registra un pedido y sus líneas, pero el servidor falla después de insertar el pedido y antes de insertar las líneas. Al arrancar, el pedido aparece sin líneas. b) Un usuario confirma una venta con COMMIT, recibe el mensaje de “venta realizada”, y un minuto después un fallo de disco hace que la venta desaparezca. c) Mientras una transacción está cambiando los precios de todos los productos (un 10 % más), otro usuario calcula el valor del inventario y obtiene una cifra en la que la mitad de los productos tienen el precio antiguo y la otra mitad el nuevo. d) Una transacción deja un producto con stock negativo, aunque existe la restricción ck_pro_stock CHECK (stock >= 0).

Ver solución
  • a) Atomicidad: el pedido y sus líneas son una unidad; tras el fallo, el SGBD debe deshacer la inserción del pedido (la transacción no se había confirmado).
  • b) Durabilidad: lo confirmado debe sobrevivir a cualquier fallo; para eso existen el redo log (y, ante la pérdida de un disco, las copias de seguridad, los redo logs archivados y el RAID).
  • c) Aislamiento: el segundo usuario no debería ver los cambios a medias de una transacción no confirmada. En Oracle, gracias a la consistencia de lectura, vería todos los precios antiguos hasta que la primera transacción hiciera COMMIT.
  • d) Consistencia: la transacción debe llevar la BD de un estado válido a otro válido; el SGBD debe rechazar la operación que viola la restricción.

Ejercicio 7: Usuarios de la base de datos

En un hospital, identifica el tipo de usuario (según el apartado 8) de cada persona:

a) La enfermera que registra las constantes de los pacientes en una tableta, eligiendo opciones de un menú. b) La persona que decide que los datos clínicos se conservarán 15 años y quién puede verlos. c) El técnico que programa las copias de seguridad y crea los usuarios en Oracle. d) La investigadora que escribe consultas SQL para estudiar la evolución de los ingresos por gripe. e) El desarrollador que programa la aplicación de citas. f) El gerente que consulta un informe mensual de ocupación de camas.

Ver solución
Persona Tipo
a) Enfermera Usuario final paramétrico
b) Política de conservación y acceso Administrador de datos (DA)
c) Copias y usuarios Administrador de la base de datos (DBA)
d) Investigadora con SQL Usuario final sofisticado
e) Desarrollador Programador de aplicaciones
f) Gerente con informe Usuario final ocasional

Ejercicio 8: Conceptos de Oracle

Responde brevemente:

a) Si se apaga el servidor, ¿qué desaparece: la instancia o la base de datos? b) Un alumno conectado a CDB$ROOT intenta crear el usuario ALUMNO05 y obtiene un error. ¿Por qué? ¿Qué debe hacer? c) Los usuarios ALUMNO01 y ALUMNO02 han creado cada uno una tabla EMPLEADOS en la misma PDB. ¿Hay conflicto? ¿Cómo se refiere ALUMNO02 a la tabla de ALUMNO01? d) ¿Qué proceso de la instancia garantiza que una transacción confirmada no se pierda? e) Una empresa necesita 5 PDB de aplicación en una misma CDB con Standard Edition 2. ¿Es posible?

Ver solución

a) Desaparece la instancia (la memoria SGA/PGA y los procesos). La base de datos (los ficheros) permanece en el disco y se vuelve a abrir al arrancar una nueva instancia.

b) En la raíz de una CDB solo se pueden crear usuarios comunes, cuyo nombre debe empezar por C##. Lo correcto es conectarse a la PDB (por ejemplo, FREEPDB1) y crear allí el usuario local ALUMNO05.

c) No hay conflicto: cada tabla pertenece a un esquema distinto (ALUMNO01.EMPLEADOS y ALUMNO02.EMPLEADOS). ALUMNO02 se refiere a la de su compañero como alumno01.empleados, siempre que tenga el privilegio de objeto correspondiente.

d) LGWR (Log Writer): en cada COMMIT escribe en los ficheros de redo log los cambios de la transacción. Si después hay una caída, la recuperación (SMON) usa ese redo para rehacer los cambios.

e) No: Standard Edition 2 admite hasta 3 PDB de usuario por CDB. Necesitaría dos CDB o la Enterprise Edition con la opción multitenant.

Ejercicios propuestos

Ejercicio 9: Arquitectura ANSI/SPARC de una biblioteca

Una biblioteca municipal tiene las tablas SOCIOS, LIBROS, EJEMPLARES y PRESTAMOS. Describe un esquema conceptual (en forma de lista de tablas y columnas), tres esquemas externos (para el personal del mostrador, para los socios desde la web y para la dirección) y tres decisiones del esquema interno. Explica qué correspondencias habría entre los niveles.

Ejercicio 10: Elección de arquitectura

Para cada caso, propón una arquitectura (dos capas, tres capas, centralizada, distribuida, con replicación…) y justifícala: (a) la aplicación de escritorio de una autoescuela con tres ordenadores; (b) una tienda online con clientes en toda Europa; (c) el sistema de reservas de una cadena hotelera con hoteles en cinco continentes; (d) la intranet de un instituto.

Ejercicio 11: Comparativa de SGBD

Elige tres SGBD de la tabla del apartado 11 y compáralos en profundidad (consulta su documentación oficial): última versión, sistemas operativos, tipos de datos destacados, herramientas de administración, opciones de alta disponibilidad, ediciones y condiciones de licencia. Termina con una recomendación razonada para una pyme que va a desarrollar un ERP propio.

Ejercicio 12: Mapa conceptual de Oracle

Elabora un mapa conceptual (puedes usar un diagrama Mermaid) que relacione: servidor, instancia, SGA, PGA, procesos de fondo, base de datos, ficheros de datos, de control y de redo log, CDB, CDB$ROOT, PDB$SEED, PDB, usuario común, usuario local, esquema y tablespace.

Resumen

Concepto Idea clave
SGBD Software que permite definir, construir, manipular, controlar y compartir bases de datos
Funciones Definición (DDL), manipulación (DML), control (integridad, seguridad, concurrencia, recuperación) y diccionario
Diccionario de datos BD interna con los metadatos; la consultan todos los componentes
ANSI/SPARC Tres niveles: externo (vistas de usuario), conceptual (toda la BD) e interno (almacenamiento físico)
Correspondencias Externa/conceptual y conceptual/interna: traducen entre niveles
Independencia física Cambiar el esquema interno sin afectar al conceptual ni a las aplicaciones
Independencia lógica Cambiar el esquema conceptual sin afectar a los externos ni a las aplicaciones
Esquema / ejemplar Estructura (intensión, estable) / datos en un momento (extensión, cambiante)
Procesador de consultas Analizador, optimizador (planes de ejecución basados en costes) y motor de ejecución
Gestor de almacenamiento Gestor de ficheros y de buffer (caché de bloques)
Gestor de transacciones Concurrencia, bloqueos, COMMIT y ROLLBACK
Registro de transacciones Log (redo en Oracle) con escritura anticipada; permite rehacer y deshacer
Lenguajes DDL (estructura), DML (datos), DCL (permisos), TCL (transacciones)
DML procedimental / no procedimental Cómo y registro a registro / qué y por conjuntos (SQL)
Lenguaje anfitrión Lenguaje de programación desde el que se usa SQL (embebido, API, ORM)
Usuarios Administrador de datos, DBA, diseñadores, programadores, usuarios finales (paramétricos, ocasionales, sofisticados, autónomos)
Transacción Unidad lógica de trabajo: todo o nada
ACID Atomicidad, Consistencia, aIslamiento, Durabilidad
Arquitecturas Centralizada, cliente/servidor, dos capas, tres capas (presentación, lógica, datos), distribuida
Oracle: servidor Instancia (SGA, PGA, procesos DBWn, LGWR, CKPT, SMON, PMON, ARCn) + base de datos (ficheros de datos, control y redo log)
Oracle: almacenamiento lógico Tablespace → segmento → extensión → bloque
Oracle: usuario y esquema El esquema es el conjunto de objetos de un usuario y tiene su mismo nombre
Oracle: multitenant CDB (CDB$ROOT, PDB$SEED) que contiene PDB; usuarios comunes (C##) y locales
Oracle: ediciones Enterprise, Standard Edition 2 y Free (2 hilos de CPU, 2 GB de RAM, 12 GB de datos)
Oracle: versiones 19c (largo plazo), 21c (innovación), 23ai, 26ai (largo plazo, actual)
Navegación  
← Módulo anterior: Historia y tipos de bases de datos Siguiente módulo: El proceso de diseño →