INTRODUCCIÓN

Por medio de esta investigación se desea comprender el funcionamiento y el

proceso de los sistemas gestores de Base de Datos. Se pretende hacer un análisis
de todo el procedimiento tomando en cuenta todos los procedimientos para así
conocer el funcionamiento de los procesos y subprocesos que se realizan y cuales
se implementaran al sistema.
Justificación
El manejo de la información, a través de bases de datos, ha evolucionado en los últimos
años hasta convertirse en parte crucial de los sistemas informáticos moderno. Como
consecuencia de esta evolución, el estudio de las Bases de Datos y de los programas
manejadores o gestores de bases de datos se ha convertido en una parte esencial de la
enseñanza de la Informática.

En ocasiones el estudiante que inicia en la carrera de informática no ha tenido experiencia

en el desarrollo de sistemas de bases de datos. Debido a esto, se elaboró esta guía de
manera que sirva de complemento para el aprendizaje de los diferentes temas tratados en
esta asignatura.

El estudiante está encargado de construir su conocimiento teniendo como recursos la

bibliografía básica y complementaria, tutoriales y apuntes colgados en el campus virtual y
los ejercicios que se asignarán durante el transcurso de la asignatura para alcanzar un
aprendizaje a partir de una sucesión de experiencias que permitan contrastar sus propias
ideas y modificar los conocimientos iniciales.
Origen de Oracle
Oracle surge en 1977 bajo el nombre de SDL (Software Development Laboratories).
En 1979, SDL cambia su nombre por Relational Software, Inc. (RSI).
La fundación de SDL fue motivada principalmente a partir de un estudio sobre los
SGBD (Sistemas Gestores de Base de Datos) de George Koch. Computer World
definió este estudio como uno de los más completos jamás escritos sobre bases de
datos. Este artículo incluía una comparativa de productos que dirigía a Relational
Software como el más completo desde el punto de vista técnico. Esto se debía a
que usaba la filosofía de las bases de datos relacionales, algo que por aquella época
era todavía desconocido.
Oracle, a partir de la versión 10g Release 2, cuenta con 7 ediciones:1
Enterprise Edition (EE).
Standard Edition (SE).
Standard Edition One (SE1)
Standard Edition 2 (SE2)
Express Edition (XE).
Personal Edition (PE).
Lite Edition (LE).

La única edición gratuita es la Express Edition, que es compatible con las demás
ediciones de Oracle Database 10gR2 y Oracle Database 11g.
La última versión de Oracle es la versión 19c. La primera base de datos diseñada
para Cloud Computing, que fue lanzada en 2013, fue Oracle 12c, con ella Oracle
intentaba facilitar los esfuerzos de las empresas para estandarizar, consolidar y
automatizar los servicios de las bases de datos en la nube.

Origen de PostgreSQL
PostgreSQL ha tenido una larga evolución, la cual se inicia en 1982 con el
proyecto Ingres en la Universidad de Berkeley. Este proyecto, liderado por Michael
Stonebraker, fue uno de los primeros intentos en implementar un motor de base de
datos relacional. Después de haber trabajado un largo tiempo en Ingres y de haber
tenido una experiencia comercial con el mismo, Michael decidió volver a la
Universidad en 1985 para trabajar en un nuevo proyecto sobre la experiencia de
Ingres, dicho proyecto fue llamado post-ingres o simplemente POSTGRES.
El proyecto post-ingres pretendía resolver los problemas con el modelo de base de
datos relacional que habían sido aclarados a comienzos de los años 1980. El
principal de estos problemas era la incapacidad del modelo relacional de
comprender "tipos", es decir, combinaciones de datos simples que conforman una
única unidad. Actualmente estos son llamados objetos. Se esforzaron en introducir
la menor cantidad posible de funcionalidades para completar el soporte de tipos.
Estas funcionalidades incluían la habilidad de definir tipos, pero también la habilidad
de describir relaciones - las cuales hasta ese momento eran ampliamente utilizadas
pero mantenidas completamente por el usuario. En Postgres la base de datos
«comprendía» las relaciones y podía obtener información de tablas relacionadas
utilizando reglas. Postgres usó muchas ideas de Ingres pero no su código.
La siguiente lista muestra los hitos más importantes en la vida del proyecto
Postgres.

 1986: se publicaron varios papers que describían las bases del sistema.
 1988: ya se contaba con una versión utilizable.
 1989: el grupo publicaba la versión 1 para una pequeña comunidad de usuarios.
 1990: se publicaba la versión 2 la cual tenía prácticamente reescrito el sistema
de reglas.
 1991: publicación de la versión 3, esta añadía la capacidad de múltiples motores
de almacenamiento.
 1993: crecimiento importante de la comunidad de usuarios, la cual demandaba
más características.
 1994: después de la publicación de la versión 4, el proyecto terminó y el grupo
se disolvió.
Después de que el proyecto POSTGRES terminara, dos graduados de la
universidad, Andrew Yu y Jolly Chen, comenzaron a trabajar sobre el código de
POSTGRES, esto fue posible dado que POSTGRES estaba licenciado bajo la BSD,
y lo primero que hicieron fue añadir soporte para el lenguaje SQL a POSTGRES,
dado que anteriormente contaba con un intérprete del lenguaje de consultas QUEL
(basado en Ingres), creando así el sistema al cual denominaron Postgres95.
Para el año 1996 se unieron al proyecto personas ajenas a la Universidad
como Marc Fournier de Hub.Org Networking Services, Bruce Momjian y Vadim B.
Mikheev quienes proporcionaron el primer servidor de desarrollo no universitario
para el esfuerzo de desarrollo de código abierto y comenzaron a trabajar para
estabilizar el código de Postgres95.
En el año 1996 decidieron cambiar el nombre de Postgres95 de tal modo que refleje
la característica del lenguaje SQL y lo terminaron llamando PostgreSQL, cuya
primera versión de código abierto fue lanzada el 1 de agosto de 1996. La primera
versión formal de PostgreSQL (6.0) fue liberada en enero de 1997. Desde entonces,
muchos desarrolladores entusiastas de los motores de base de datos se unieron al
proyecto, coordinaron vía Internet y entre todos comenzaron a incorporar muchas
características al motor.
Aunque la licencia permitía la comercialización de PostgreSQL, el código no se
desarrolló en principio con fines comerciales, algo sorprendente considerando las
ventajas que PostgreSQL ofrecía. La principal derivación se originó cuando Paula
Hawthtorn (un miembro del equipo original de Ingres que se pasó a Postgres)
y Michael Stonebraker conformaron Illustra Information Technologies para
comercializar Postgres.
En 2000, ex inversionistas de Red Hat crearon la empresa Great Bridge para
comercializar PostgreSQL y competir contra proveedores comerciales de bases de
datos. Great Bridge auspició a varios desarrolladores de PostgreSQL y donó
recursos de vuelta a la comunidad, pero a fines de 2001 cerró debido a la dura
competencia de compañías como Red Hat y pobres condiciones del mercado.
En 2001, Command Prompt, Inc. lanzó Mammonth PostgreSQL, la más antigua
distribución comercial de PostgreSQL. Continúa brindando soporte a la comunidad
PostgreSQL a través del auspicio de desarrolladores y proyectos, incluyendo
PL/Perl, PL/php y el alojamiento de proyectos de comunidades como PostgreSQL
Build Farm.
En enero de 2005, PostgreSQL recibió apoyo del proveedor de base de
datos Pervasive Software, conocido por su producto Btrieve que se utilizaba en la
plataforma Novell Netware. Pervasive anunció soporte comercial y participación
comunitaria y logró algo de éxito. Sin embargo, en julio de 2006 dejó el mercado de
soporte de PostgreSQL.
A mediados de 2005 otras dos compañías anunciaron planes para comercializar
PostgreSQL con énfasis en nichos separados de mercados. EnterpriseDB añadió
funcionalidades que le permitían a las aplicaciones escritas para trabajar con Oracle
ser más fáciles de ejecutar con PostgreSQL. Greenplum contribuyó mejoras
directamente orientadas a aplicaciones de Data Warehouse e Inteligencia de
negocios, incluyendo el proyecto BizGres.
En octubre de 2005, John Loiacono, vicepresidente ejecutivo de software en Sun
Microsystems comentó: "No estamos yendo tras el OEM de Microsoft pero estamos
viendo a PostgreSQL ahora", aunque no se dieron especificaciones en ese
momento. Para noviembre de 2005, Sun Solaris 10 (lanzamiento 6/06) incluía
PostgreSQL.
En agosto de 2007 EnterpriseDB anunció el Postgres Resource Center y
EnterpriseDB Postgres, diseñados para ser una distribución de PostgreSQL
completamente configurada, incluyendo muchos módulos contribuidos y agregados.
EnterpriseDB Postgres fue renombrado Postgres Plus en marzo de 2008.
El proyecto PostgreSQL continúa haciendo lanzamientos principales anualmente y
lanzamientos menores de reparación de bugs, todos disponibles bajo la licencia
PostgreSQL, y basados en contribuciones de proveedores comerciales, empresas
aportantes y programadores de código abierto mayormente.

Origen de Microsoft SQL Server

La historia de SQL (que se pronuncia deletreando en inglés las letras que lo
componen, es decir "ese-cu-ele" y no "siquel" como se oye a menudo) empieza en
1974 con la definición, por parte de Donald Chamberlin y de otras personas que
trabajaban en los laboratorios de investigación de IBM, de un lenguaje para la
especificación de las características de las bases de datos que adoptaban
el modelo relacional. Este lenguaje se llamaba SEQUEL (Structured English Query
Language) y se implementó en un prototipo llamado SEQUEL-XRM entre 1974 y
1975. Las experimentaciones con ese prototipo condujeron, entre 1976 y 1977, a
una revisión del lenguaje (SEQUEL/2), que a partir de ese momento cambió de
nombre por motivos legales, convirtiéndose en SQL. El prototipo (System R),
basado en este lenguaje, se adoptó y utilizó internamente en IBM y lo adoptaron
algunos de sus clienteselegidos. Gracias al éxito de este sistema, que no estaba
todavía comercializado, también otras compañías empezaron a desarrollar
sus productosrelacionales basados en SQL. A partir de 1981, IBM comenzó a
entregar sus productos relacionales y en 1983 empezó a vender DB2. En el curso
de los años ochenta, numerosas compañías (por ejemplo Oracle y Sybase, sólo por
citar algunos) comercializaron productos basados en SQL, que se convierte en el
estándar industrial de hecho por lo que respecta a las bases de datos relacionales.
En 1986, el ANSI adoptó SQL (sustancialmente adoptó el dialecto SQL de IBM)
como estándar para los lenguajes relacionales y en 1987 se transfomó en
estándar ISO. Esta versión del estándar va con el nombre de SQL/86. En los años
siguientes, éste ha sufrido diversas revisiones que han conducido primero a la
versión SQL/89 y, posteriormente, a la actual SQL/92.

El hecho de tener un estándar definido por un lenguaje para bases de datos

relacionales abre potencialmente el camino a la intercomunicabilidad entre todos los
productos que se basan en él. Desde el punto de vista práctico, por desgracia las
cosas fueron de otro modo. Efectivamente, en general cada productor adopta e
implementa en la propia base de datos sólo el corazón del lenguaje SQL (el así
llamado Entry level o al máximo el Intermediate level), extendiéndolo de manera
individual según la propia visión que cada cual tenga del mundo de las bases de
datos.
Actualmente, está en marcha un proceso de revisión del lenguaje por parte de los
comités ANSI e ISO, que debería terminar en la definición de lo que en este
momento se conoce como SQL3. Las características principales de esta nueva
encarnación de SQL deberían ser su transformación en un lenguaje stand-alone
(mientras ahora se usa como lenguaje hospedado en otros lenguajes) y
la introducción de nuevos tipos de datos más complejos que permitan, por ejemplo,
el tratamiento de datos multimediales.

Características de Oracle

 Modelo relacional: los usuarios visualizan los datos en tablas con el formato
filas/columnas.
 Herramienta de administración gráfica intuitiva y cómoda de utilizar.
 Control de acceso: tecnologías avanzadas para vigilar la entrada a los datos.
 Protección de datos: seguridad completa en el entorno de producción y de
pruebas y gestión de copias de seguridad.
 Lenguaje de diseño de bases de datos muy completo (PL/SQL): permite
implementar diseños "activos", que se pueden adaptar a las necesidades
cambiantes de negocio.
 Alta disponibilidad: escalabilidad, protección y alto rendimiento para la actividad
empresarial.
 Gestión de usuarios: agilidad en los trámites, reducción de costes y seguridad
en el control de las personas que acceden a las aplicaciones y a los sistemas.

Características de PostgreSQL

 El lenguaje SQL que usa es muy próximo al estándar ISO/IEC, gracias a lo

que resulta relativamente sencillo portar consultas y scripts de otros sistemas
de bases de datos, y así aprender fácilmente las variantes de este lenguaje.
 Cumple con ACID, es decir provee atomicidad, consistencia, aislamiento y
durabilidad para sus operaciones.
 Permite crear esquemas, tablas heredadas y triggers orientados a eventos
que no poseen otros motores.
 Permite definir procedimientos, no solo en PostgreSQL, sino también en otros
muchos lenguajes como Pearl, TCL o Python. Incluso si lenguaje que
queramos usar no está soportado, podemos definirlo con nuevas extensiones.
  Si necesitamos algún tipo de dato que no esté soportado de serie, también
podemos definirlos.
 Podemos extender la funcionalidad con extensiones, provistas por la propia
PostgreSQL, por terceros o incluso programando por nuestra cuenta.
 Tiene un soporte nativo de replicación maestro-esclavo, pero también es
posible añadir otros tipos a través de productos de terceros, libres o de pago.
 También provee una excelente escalabilidad vertical.

Características de Microsoft SQL Server

 Soporte de transacciones.
 Soporta procedimientos almacenados.
 Incluye también un entorno gráfico de administración, que permite el uso
de comandos DDL y DML gráficamente.
 Permite trabajar en modo cliente-servidor, donde la información y datos se
alojan en el servidor y los terminales o clientes de la red sólo acceden a la
información.
 Además permite administrar información de otros servidores de datos.
 Este sistema incluye una versión reducida, llamada MSDE con el mismo motor
de base de datos pero orientado a proyectos más pequeños, que en sus
versiones 2005 y 2008 pasa a ser el SQL Express Edition, que es una edición
Open Source ,es decir, se distribuye en forma gratuita.
 Es común desarrollar proyectos completos empleando Microsoft SQL
Server y Microsoft Access a través de los llamados ADP (Access Data Project).
De esta forma se completa la base de datos (Microsoft SQL Server), con el
entorno de desarrollo (VBA Access), a través de la implementación de
aplicaciones de dos capas mediante el uso de formularios Windows.
 En el manejo de SQL mediante líneas de comando se utiliza el SQLCMD, osql,
o PowerShell.
 Para el desarrollo de aplicaciones más complejas (tres o más capas), Microsoft
SQL Server incluye interfaces de acceso para varias plataformas de desarrollo,
entre ellas .NET, pero el servidor sólo está disponible para Sistemas
Operativos.
 El tipo NUMERIC fue mejorado para ser usado como identificador de columna
a partir de la versión 2008 R2.
Arquitectura de Oracle
Un sistema de base de datos Oracle consta de 2 partes, la base de datos en sí y
una instancia de la base de datos. La base de datos consta de estructuras físicas y
lógicas, mientras que la instancia consta de estructuras de memoria y de procesos
asociados con dicha instancia.

Cada vez que se arranca una instancia, se reserva un espacio de memoria (SGA)
y se arrancan una serie de procesos. Después de arrancar la instancia de la base
de datos, el software de la base de datos se encarga de asociarla con una base
de datos específica, lo que se denomina “montar la base de datos”. A partir de este
momento la base de datos está lista para ser abierta, lo que permite a los usuarios
conectarse a ella.
Cada instancia de la base de datos está relacionada con solo y solo una base de
datos. Una instancia de base de datos no puede ser compartida. En un RAC (Real
Application Cluster), normalmente existen varias instancias de base de datos en
diferentes servidores que comparten la misma base de datos. En este modelo la
misma base de datos está relacionada con varias instancias, y cada instancia
únicamente con una base de datos.

Estructuras de Memoria:
Como comentábamos anteriormente, una instancia de base de datos consta de un
área de memoria y una serie de procesos que se hacen llamar “procesos de
background”. Cada vez que una instancia se levanta, se reserva un área de
memoria denominada SGA (System Global Area), y se ejecutan los procesos
asociados.
Existen 2 estructuras básicas de memoria en una instancia de base de datos:
System Global Area (SGA): Esta estructura de memoria es una memoria
compartida, ya que tanto el servidor como los procesos de background tienen
acceso a dicha área de memoria.
Program Global Area (PGA): Esta región de memoria es una memoria privada,
que solo es accesible por los procesos del servidor o de background. La PGA por
tanto no es una memoria compartida, cada proceso tiene su propia PGA.

SGA
Database Buffer Cache: Como sabemos Oracle trabaja con bloques de datos
(mínima cantidad de información que almacena Oracle y que por defecto suelen
ser 8 kb) y no con filas. En esta parte de memoria se almacenan imágenes de los
bloques de datos físicos (de disco) utilizados para realizar consultas o que han
sido modificados por una sentencia. Siempre que un proceso necesite una
determinada información buscará dichos datos en el Database Buffer Cache. Si
encuentra la información aquí podrá leer los datos directamente desde memoria
(cache hit). Si por lo contrario, el proceso no encuentra la información solicitada en
el buffer, tendrá que hacer un acceso a disco y traerse los bloques de datos
necesarios a memoria. (cache miss). Cuando Oracle modifica los datos, lo hace
directamente sobre el Database Buffer Cache. Estos bloques modificados se
denominan bloques sucios o “Dirty Blocks”. La actualización de los bloques en el
Database Buffer Cache se realiza por el algoritmo LRU.
Redo Log Buffer: El Redo Log Buffer se podría definir como una bitácora. Esta
parte de la memoria actúa como un buffer circular y es donde se registrarán todos
los cambios que se produzcan en la base de datos, entendiendo por cambios la
ejecución de las sentencias DML (Insert, Update, Delete, Merge) y DDL
(Create, Alter, Drop, Truncate). Estas entradas de redo se almacenarán por si
fuese necesario una recuperación de la base de datos. Según los procesos vayan
haciendo cambios, se irán generando nuevas entradas de redo que se irán
escribiendo en la SGA. Estas entradas se irán almacenando de forma secuencial
en el buffer y será el proceso de background “Log Writer” (LGWR) el que se
encargará de escribir esta información en el fichero físico de log de redo.
Shared Pool: El área de memoria que comprende la Shared Pool contiene la
“library cache”, “el data dictionary cache” y el “result cache”.
El “data dictionary cache” es una especie de metadatos de la base de datos, es en
definitiva una colección de tablas y vistas que contienen información de la base de
datos, sus estructuras y sus usuarios. Es una zona bastante accedida de la base
de datos.
Otra área es la “library cache”. Es sin duda otra zona bastante concurrida de la
base de datos. Oracle representa cada sentencia SQL que se ejecuta con una
zona SQL compartida, con lo que Oracle es capaz de reconocer cuando 2 usuarios
ejecutan la misma sentencia, y así poder reutilizar la misma área para ambos
usuarios. Esta zona de memoria compartida contiene el plan de ejecución, con lo
que Oracle ahorra memoria utilizando la misma área para las sentencias que se
ejecutan en múltiples ocasiones.
En la “result cache” se almacenan filas y no bloques. En este área por ejemplo
podemos guardar listas de valores muy utilizadas. Para ello tendremos que definir
un tipo de Hint especial en nuestras consultas que hagan que los resultados
obtenidos se almacenen en esta cache.
Large Pool: Esta zona es opcional. El administrador del sistema puede configurarla
siempre que quiera reservar memoria para realizar operaciones de backup o
recuperación de la base de datos o consultas en paralelo.
Java Pool: Esta zona se utiliza para almacenar código Java almacenado y datos
de la JVM. Es a partir de la versión 8i de Oracle a partir de la cual tenemos
disponible esta característica.
Stream Pool: Zona de memoria utilizada para almacenar Oracle Streams.
Normalmente se usa en la configuración de Data Guards (Replicaciones de datos,
donde a partir de este buffer se irá enviando datos a una base de datos
secundaria). A menos que se haya configurado, el tamaño de esta zona de
memoria será de 0 kb.
Keep, Recyble Pools: Estas zonas de memorias son similares a la Database
Buffer Cache, pero se difieren en que son diseñados para mantener la información
más o menos tiempo de lo que la retendría el algoritmo LRU.
Con la infraestructura dinámica de la SGA, el tamaño de los buffers puede ser
alterado sin parar la base de datos. La base de datos utiliza una serie de
parámetros de inicialización para crear y manejar las estructuras de memoria. La
manera más simple de controlar la memoria de la base de datos es dejar a la base
de datos que lo haga de forma automática. Para conseguirlo, lo único que
tendremos que hacer es establecer 2 parámetros de configuración:
MEMORY_TARGET y MEMORY_MAX_TARGET.
PGA
La Program Global Area, es una región privada de memoria que contiene datos e
información de control de los procesos del servidor. Cada proceso tiene su
propia PGA, y el acceso a dicha información es totalmente exclusivo.
En un servidor dedicado, cada proceso tendrá un espacio de pila y una zona
denominada User Global Area (UGA). En un servidor compartido, en el cual
múltiples usuarios comparten el mismo proceso servidor, éste solo tendrá el
espacio de pila, mientras que la UGA se almacenará en la SGA.
Arquitectura de PostgreSQL

El siguiente gráfico muestra de forma esquemática las entidades involucradas en el

funcionamiento normal del gestor de bases de datos:

PostgreSQL está basado en una arquitectura cliente-servidor. El programa servidor

se llama postgres y entre los muchos programas cliente tenemos, por ejemplo,
pgaccess (un cliente gráfico) y psql (un cliente en modo texto).

Un proceso servidor postgres puede atender exclusivamente a un solo cliente; es

decir, hacen falta tantos procesos servidor postgres como clientes haya. El proceso
postmaster es el encargado de ejecutar un nuevo servidor para cada cliente que
solicite una conexión.

Se llama sitio al equipo anfitrión (host) que almacena un conjunto de bases de datos
PostgreSQL. En un sitio se ejecuta solamente un proceso postmaster y múltiples
procesos postgres. Los clientes pueden ejecutarse en el mismo sitio o en equipos
remotos conectados por TCP/IP.

Es posible restringir el acceso a usuarios o a direcciones IP modificando las

opciones del archivo pg_hba.conf, que se encuentra en
/etc/postgresql/pg_hba.conf.

Este archivo, junto con /etc/postgresql/postgresql.conf son particularmente

importantes, porque algunos de sus parámetros de configuración por defecto
provocan multitud de problemas al conectar inicialmente y porque en ellos se
especifican los mecanismos de autenticación que usará PostgreSQL para verificar
las credenciales de los usuarios.

Para habilitar la conexión a PostgreSQL desde clientes remotos, debemos verificar

el parámetro tcpip_socket = true en el fichero /etc/postgresql/postgresql.conf.
A continuación, para examinar los métodos de autenticación y las posibilidades de
conexión de clientes externos, debemos mirar el fichero /etc/postgresql/
pg_hba.conf, donde se explicita la acción que hay que emprender para cada
conexión proveniente de cada host externo, o grupo de hosts.

Arquitectura de Microsoft SQL Server

La arquitectura interna de las bases de datos en SQL Server están compuestas por
2 tipos de estructura, la estructura lógica y la estructura física. Es muy importante
conocer cómo es que estas estructuras están compuestas y cuál es la relación que
tienen los objetos de base de datos con cada una de estas estructuras.

Estructura Lógica:

Desde el punto de vista lógico, la base de datos debe tener al menos 1 “FileGroup”
el cual contiene a toda la metadata de la misma base de datos, es decir tablas y
vistas de sistema, a este “FileGroup” inicial se le conoce como “Primario” y está
presente en todas las bases de datos. Todos los objetos de usuario que contengan
data, ya sean tablas o índices, deben estar ligados a un “FileGroup”, esto se puede
definir al momento de ejecutar la sentencia DDL de creación del objeto, si no se
indica a que “FileGroup” estará ligado ese objeto, este pertenecerá al “FileGroup”
por defecto definido en la base de datos. La base de datos solo puede tener definido
1 solo default “FileGroup”.

Las bases de datos pueden tener hasta 32767 “FileGroups” definidos, según los
límites establecidos para la última versión de SQL Server, la cual es SQL Server
2008 R2. Uno de los propósitos de los “FileGroups” es poder distribuir la data a
través de varios discos duros físicos, de esta manera se puede obtener mayor
rendimiento en las operaciones de I/O debido a que más de un disco trabajara al
mismo tiempo. Otro de los propósitos es poder esconder la ubicación física real de
la información a los programadores, ya que para ellos la tabla “X” pertenece al
“FileGroup” “A”, pero no saben en que data files físicamente se encuentra la
información de la tabla “X”.

Los “FileGroups” pueden contener 1 o más “Datafiles”, y cada uno de estos datafiles
se pude encontrar en un discos diferentes, lo cual también agilizara las consultas y
los ingresos de información a las tablas que se encuentren asignadas a este
“FileGroup”, debido a que SQL Server distribuirá la información uniformemente a
través de todos los “DataFiles” del “FileGroup”.

Estructura Física:

Desde el punto de vista físico, como ya hemos visto, tenemos los “DataFiles” que
los en realidad los archivos de datos, es decir donde se guarda toda la información
de la base de datos. Un “DataFile” solo puede pertenecer a 1 “FileGroup”.

Internamente los “DataFiles” están divididos en “Extends” y estos a su vez en

“Pages”. Las “Pages” son la unidad minima de almacenamiento dentro de la base
de datos. Un “Page” tiene 8 Kb de tamaño en espacio de disco. Un “Extend” tiene 8
“Pages” contiguas que lo conforman, es decir, un “Extend” tiene como tamaño 64
Kb de espacio en disco.

En un “Page” solo puede haber información de 1 sola tabla, es decir el espacio de

un “Page” no es compartido entre tablas o índices. En el caso de los “Extends”,
estos pueden ser de dos tipos:

 “Mixed”: Los cuales son compartidos hasta por 8 objetos, uno por cada “Page”.
 “Uniform”: Los cuales solo pertenecen a un solo objeto, es decir que todos los
“Pages” pertenecen a un solo objeto.

Normalmente cuando se crea una nueva tabla esta es asignada a un “Extend” de

tipo “Mixed”, hasta alcanzar la utilización de hasta 8 “Pages”, a partir de ese
momento se asignan “Extends” de tipo “Uniform” para optimizar el uso del espacio
en la tabla.

Los “DataFiles” normalmente tienen 2 extensiones de archivo, las cuales son

estandar mas no obligarias, la extencion “mdf” que se utiliza para el primer “Datafile”
perteneciente al “FileGroup” primario, y la extension “ndf” que se utiliza para los
demas datafiles que se agregan posteriormente a los demas “FileGroups” de la base
de datos.

En el caso del “LogFile”, este no pertenece a un “FileGroup” en especifico, en

cambio archivo esta ligado directamente a la base de datos. Las bases de datos de
SQL Server solo pueden tener un solo “LogFile” activo al mismo tiempo, si bien se
pueden crear multiples “LogFiles” en la base de datos, solo uno podra ser escrito,
ya que solo uno puede estar activo, cuando este archivo se llene, la base de datos
pasara a escribir al siguiente archivo de transacciones, y asi sucesivamente. Por
esta razon no es muy conveniente ni util tener mas de un “LogFile”.

En conclusión espero que sea de ayuda estas explicaciones sobre la arquitectura

de una base de datos de SQL Server, si desean temas por favor no duden en
solicitarlo, haré lo posible para poder cubrir los temas solicitados en el mas corto
tiempo.
Manipulación de los datos de Oracle, PostgreSQL,
Microsoft SQL Server

Elementos del lenguaje de manipulación de datos

SELECT
La sintaxis básica de select es la siguiente utilizando el estándar de SQL:

select columna from tabla;

donde se sustituye la palabra columna por el nombre del campo a consultar y la

palabra tabla por el nombre de la tabla que contiene el campo mencionado.
Insert
La estructura básica para la sentencia insert utilizando el estándar de SQL es la
siguiente:

insert into usuario (nombre, apellidos, edad, carrera) values ("Martín", "Bastida
Godínez", "23", "Ingeniería en TI");

Tomando como ejemplo si se tuviera una tabla llamada 'usuario' con los campos de
tipo cadena de caracteres (nombre, apellidos, edad, carrera), donde se inserta los
valores que se encuentran en después de la palabra values, los valores se insertan
en el orden correspondiente a como se hizo la llamada de los campos, los valores
van separados por comas, las comillas dobles indican que se está insertando datos
de tipo cadena de caracteres.
Delete
Para eliminar los registros de una tabla usamos el comando "delete":

delete from usuarios;

La ejecución del comando indicado en la línea anterior borra TODOS los registros
de la tabla.
Si queremos eliminar uno o varios registros debemos indicar cuál o cuáles, para ello
utilizamos el comando "delete" junto con la cláusula "where" con la cual
establecemos la condición que deben cumplir los registros a borrar. Por ejemplo,
queremos eliminar aquel registro cuyo nombre de usuario es 'Martín':

delete from usuarios where nombre='Martín';

Si solicitamos el borrado de un registro que no existe, es decir, ningún registro

cumple con la condición especificada, no se borrarán registros, pues no encontró
registros con ese dato.
Update
Para modificar uno o varios datos de uno o varios registros
utilizamos "update" (actualizar).
Por ejemplo, en nuestra tabla "usuarios", queremos cambiar los valores de todas
las claves, por "Sevilla":

update usuarios set clave='Sevilla';

Utilizamos "update" junto al nombre de la tabla y "set" junto con el campo a

modificar y su nuevo valor.
El cambio afectará a todos los registros.
Podemos modificar algunos registros, para ello debemos establecer condiciones de
selección con "where".
Por ejemplo, queremos cambiar el valor correspondiente a la clave de nuestro
usuario llamado 'Martín', queremos como nueva clave 'Boca', necesitamos una
condición "where" que afecte solamente a este registro:

update usuarios set clave='Boca'

where nombre='Martín';

Si no encuentra registros que cumplan con la condición del "where", ningún registro
es afectado.
Las condiciones no son obligatorias, pero si omitimos la cláusula "where", la
actualización afectará a todos los registros.
También se puede actualizar varios campos en una sola instrucción:

update usuario set nombre='MarceloDuarte', clave='Marce'

where nombre='Marcelo';

Para ello colocamos "update", el nombre de la tabla, "set" junto al nombre del campo
y el nuevo valor y separado por coma, el otro nombre del campo con su nuevo valor.

Clasificación de los DML

Se clasifican en dos grandes grupos de:

 lenguajes de consulta procedimentales

Lenguajes procedimentales. En este tipo de lenguaje el usuario da instrucciones al
sistema para que realice una serie de procedimientos u operaciones en la base de
datos para calcular un resultado final.

 lenguajes de consulta no procedimentales

En los lenguajes no procedimentales el usuario describe la información deseada sin
un procedimiento específico para obtener esa información.
Seguridad e integridad de los datos de Oracle,
PostgreSQL, Microsoft SQL Server

La seguridad de la información se ocupa de proteger la confidencialidad,

disponibilidad e integridad en base de datos de todos los activos de conocimiento
de la organización. La forma de lograrlo tiene que ver con:

Confidencialidad: se trata del aspecto más importante de la seguridad de base de

datos. Este objetivo se alcanza a través del La encriptación ha de aplicarse a datos
en reposo, pero también a los datos que, por un motivo u otro, se encuentren en
tránsito.

Integridad en base de datos: busca garantizar que sólo las personas autorizadas a
ello podrán acceder a información privilegiada de la empresa. La integridad de una
base de datos se aplica a través de protocolos de autenticación, políticas internas
(como las que impulsan la seguridad de las contraseñas) y un sistema de control de
acceso de usuario que define los permisos que determinan quién puede acceder a
qué datos. Tampoco puede olvidarse el tomar medidas que ayuden a conseguir que
las cuentas no utilizadas queden bloqueadas o sean eliminadas.

Disponibilidad: hace referencia a la necesidad de que las bases de datos y toda la

información que contienen estén listas para su uso. Por una parte, se debe
garantizar su funcionalidad y confiabilidad mientras que, por otra, es recomendable
planificar los tiempos de inactividad fuera del horario laboral.

Garantizar la integridad en base de datos, así como su disponibilidad y confiabilidad

es determinante para el buen funcionamiento del negocio. Sin embargo, la amenaza
no da tregua y, a día de hoy, los ataques se multiplican, tanto en frecuencia, como
en objetivo. Los piratas informáticos ya no codician sólo los activos informacionales
de las grandes corporaciones multinacionales, sino que tienen en su punto de mira
a todo tipo de empresas, independientemente de su tamaño, propósito o industria.

Recuperación y restauración de los datos de Oracle,

PostgreSQL, Microsoft SQL Server

La copia de seguridad, también llamada respaldo o backup, se refiere a la copia de

archivos físicos o virtuales o bases de datos a un sitio secundario para su
preservación en caso de falla del equipo u otra catástrofe. El proceso de copia de
seguridad de los datos es fundamental para un plan de recuperación de desastres
(DRP) exitoso.

¿Qué son el respaldo y la recuperación?

Las empresas hacen una copia de seguridad (respaldo) de los datos que
consideran vulnerables en caso de software defectuoso, corrupción de datos, falla
de hardware, piratería maliciosa (hacking), error de usuario u otros eventos
imprevistos. Las copias de seguridad capturan y sincronizan una instantánea de
un punto en el tiempo que luego se usa para devolver los datos a su estado
anterior.

Las pruebas de copia de seguridad y recuperación examinan las prácticas y

tecnologías de una organización para la seguridad y la replicación de datos. El
objetivo es garantizar una recuperación de datos rápida y confiable en caso de que
surja la necesidad. El proceso de recuperación de archivos de datos respaldados
se conoce como restauración de archivos.

Los términos copia de seguridad de datos y protección de datos a menudo se usan

indistintamente, aunque la protección de datos abarca los objetivos más amplios
de continuidad empresarial, seguridad de datos, administración del ciclo de vida
de la información y prevención de malware y virus informáticos.

¿Qué datos se deben respaldar y con qué frecuencia?

Un proceso de copia de seguridad se aplica a las bases de datos críticas o

aplicaciones de línea de negocio relacionadas. El proceso se rige por políticas
predefinidas de respaldo que especifican la frecuencia con la que se realiza la
copia de seguridad de los datos y la cantidad de copias duplicadas (conocidas
como réplicas), así como los acuerdos de nivel de servicio (SLA) que estipulan la
rapidez con la que se deben restaurar los datos.

Las mejores prácticas sugieren que se debe programar una copia de seguridad
completa de los datos al menos una vez a la semana, a menudo durante los fines
de semana o fuera del horario laboral. Para complementar las copias de seguridad
completas semanales, las empresas generalmente programan una serie de tareas
de respaldo de datos incrementales o diferenciales que solo realizan copias de los
datos que han cambiado desde la última copia de seguridad completa.

Medios de almacenamiento de copia de seguridad

Las empresas suelen realizar respaldo de datos clave en dispositivos de copia de

seguridad dedicados o sistemas de cinta magnéticos. Los sistemas de
deduplicación de datos contienen unidades de disco duro (HDD) y están
equipados con software para establecer políticas de respaldo.
Los sistemas de copia de seguridad de disco a disco aparecieron inicialmente
como una alternativa a las bibliotecas de unidades de cinta de copia de seguridad
magnética. Tanto el disco como la cinta todavía se usan hoy, y con frecuencia en
conjunto.

A medida que aumentan los tamaños de los archivos, algunos proveedores de

sistemas de respaldo han lanzado al mercado dispositivos de protección de datos
integrados para simplificar el proceso de copia de seguridad. Un dispositivo de
datos integrado es esencialmente un servidor de archivos equipado con HDD y
software de respaldo desarrollado por el proveedor. Estos dispositivos de
almacenamiento de datos plug-and-play a menudo incluyen funciones
automatizadas para monitorear la capacidad del disco, el almacenamiento
expandible y las bibliotecas de cintas preconfiguradas.

La mayoría de los dispositivos de respaldo basados en disco permiten que las

copias se muevan de medios giratorios a cintas magnéticas para una retención a
largo plazo. Los sistemas de cinta magnética todavía se utilizan como medios de
respaldo debido al aumento de las densidades de cinta y al aumento de los
sistemas de archivo de cinta lineal.

Una biblioteca de cintas virtuales (VTL) proporciona una opción menos costosa
para una matriz de deduplicación. Una VTL es un sistema basado en disco cuyo
comportamiento imita al de una biblioteca de cintas físicas.

Las unidades de estado sólido (SSD) generalmente no se utilizan para la copia de

seguridad de datos debido a problemas de tecnología de la red. Algunos
proveedores de almacenamiento incluyen SSD como una herramienta de
almacenamiento en caché o de niveles para administrar escrituras
con arrays basados en disco. Los datos se almacenan inicialmente en caché en el
almacenamiento flash y luego se escriben en el disco.

Copia de seguridad local vs. respaldo sin conexión para el almacenamiento

primario

Los sistemas de almacenamiento primario modernos han evolucionado para

ofrecer capacidades nativas más sólidas para el respaldo de datos. Estas
características incluyen esquemas avanzados de protección RAID, instantáneas
ilimitadas y herramientas para replicar instantáneas en una copia de seguridad
secundaria o incluso en una copia de seguridad terciaria externa. A pesar de estos
avances, el respaldo basado en el almacenamiento primario tiende a ser más
costoso y carece de las capacidades de indexación que se encuentran en los
productos de copia de seguridad tradicionales. La deduplicación de datos, por
ejemplo, apareció por primera vez en los dispositivos de respaldo de EMC Data
Domain, pero gradualmente se está convirtiendo en una característica de
referencia de los arreglos de almacenamiento primario de marca.

Los respaldos locales colocan copias de datos en discos duros externos o

sistemas de cinta magnética, que generalmente se encuentran en o cerca de un
centro de datos local. Los datos se transmiten a través de una conexión de red
segura de banda ancha o de una intranet corporativa.

Una de las ventajas de la copia de seguridad local es la capacidad de realizar una

copia de seguridad de los datos detrás de un firewall de red. La copia de seguridad
local también es mucho más rápida y proporciona un mayor control sobre quién
puede acceder a los datos.

La copia de seguridad sin conexión o en frío es similar al respaldo local, aunque a

menudo se asocia con la copia de seguridad de una base de datos. Un respaldo
fuera de línea incurre en tiempo de inactividad desde que se realiza el proceso de
copia de seguridad mientras la base de datos está desconectada de su red.

Respaldo y almacenamiento en la nube

A la inversa, la copia de seguridad fuera del sitio transmite copias de datos a una
ubicación remota, que puede incluir el centro de datos secundario de una empresa
o la instalación de colocación arrendada. Cada vez más, la copia de seguridad de
datos fuera del sitio equivale al almacenamiento en la nube basado en suscripción
como un servicio, que proporciona una capacidad escalable y de bajo costo y
elimina la necesidad del cliente de comprar y mantener hardware de respaldo. A
pesar de su creciente popularidad, la elección de la copia de seguridad como un
servicio requiere que los usuarios cifren los datos y tomen otras medidas para
salvaguardar la integridad de los datos.

El respaldo en la nube se divide en lo siguiente:

Almacenamiento público en la nube: los usuarios envían datos a un proveedor de
servicios en la nube, que les cobra una tarifa de suscripción mensual basada en el
almacenamiento consumido. Hay tarifas adicionales por ingreso y egreso de datos.
Amazon Web Services (AWS), Google Compute Engine y Microsoft Azure son
actualmente los mayores proveedores de nube pública.

Almacenamiento en la nube privada: se realiza un respaldo de los datos en

diferentes servidores dentro del firewall de la compañía, generalmente entre un
centro de datos local y un sitio de recuperación de desastres secundario. Por esta
razón, el almacenamiento en la nube privada a veces se denomina
almacenamiento interno en la nube.

Almacenamiento híbrido en la nube: una empresa usa almacenamiento local y

externo. Las empresas suelen utilizar el almacenamiento en la nube pública de
forma selectiva para el archivo de datos y la retención a largo plazo. Utilizan el
almacenamiento privado para el acceso local y la copia de seguridad para un
acceso más rápido a sus datos más críticos.

La mayoría de los proveedores de copias de seguridad permiten respaldar las

aplicaciones locales en una nube privada dedicada, tratando de manera efectiva
la copia de seguridad de datos basada en la nube como una extensión del centro
de datos físico del cliente. También conocido como recuperación de desastres
como un servicio (DRaaS), este campo de maduración permite a una organización
arrendar espacio en los servidores de almacenamiento de un proveedor de
servicios para la copia de seguridad centralizada y la gestión de datos de la línea
de vida.

La copia de seguridad de datos de nube a nube es un enfoque alternativo que ha

ido ganando impulso. Con este método, los datos de un cliente se copian de una
plataforma de copia de seguridad en la nube a otra nube. También se refiere a las
copias de seguridad basadas en la nube de datos almacenados en plataformas de
software como servicio (SaaS).