Sistema de gestin de bases de datos

Un Sistema de Gestin de Bases de Datos (SGBD) es un conjunto de programas que permiten el

almacenamiento, modificacin y extraccin de la informacin en una base de datos, adems de
proporcionar herramientas para aadir, borrar, modificar y analizar los datos. Los usuarios pueden
acceder a la informacin usando herramientas especficas de interrogacin y de generacin de informes,
o bien mediante aplicaciones al efecto Los SGBD tambin proporcionan mtodos para mantener la
integridad de los datos, para administrar el acceso de usuarios a los datos y para recuperar la
informacin si el sistema se corrompe. Permite presentar la informacin de la base de datos en variados
formatos. La mayora de los SGBD incluyen un generador de informes. Tambin puede incluir un
mdulo grfico que permita presentar la informacin con grficos y tablas .
Hay muchos tipos de SGBD distintos segn manejen los datos y muchos tamaos distintos segn
funcionen sobre ordenadores personales y con poca memoria a grandes sistemas que funcionan
enmainframes con sistemas de almacenamiento especiales.
Generalmente se accede a los datos mediante lenguajes de interrogacin, lenguajes de alto nivel que
simpifican la tarea de construir las aplicaciones. Tambin simplifican la interrogacin y la presentacin
de la informacin. Un SGBD permite controlar el acceso a los datos, asegurar su integridad, gestionar el
acceso concurrente a ellos, recuperar los datos tras un fallo del sistema y hacer copias de seguridad.
Las Bases de Datos y los sistemas para su gestin son esenciales para cualquier rea de negocio, y
deben ser gestionados con esmero.
ndice
[ocultar]
1 Introduccin
2 Historia
o 2.1 Sistemas de navegacin de 1960
o 2.2 Sistemas relacionales de 1970
o 2.3 Sistemas SQL de finales de la dcada 1970
o 2.4 Sistemas orientados a objetos de 1980
o 2.5 Sistemas NoSQL de 2000
o 2.6 Sistemas XML 2010
3 Componentes
4 Lenguajes de modelacin
o 4.1 Estructura jerrquica
o 4.2 Estructura en red
o 4.3 La estructura relacional
o 4.4 La estructura multidimensional
o 4.5 La estructura orientada a objetos
5 Lenguajes de consulta
6 Arquitectura
7 Vase tambin
8 Referencias
Introduccin[editar editar cdigo]
Las Bases de Datos generalmente funcionan en ordenadores dedicados. Por las prestaciones
requeridas, generalmente funcionan en ordenadores multi-procesador con abundante memoria. Para el
almacenaje de los datos puede contar con sistemas de disco propio (DAS), puede conectarse a una red
de almacenamiento (SAN) o conectarse a un sistema de almacenamiento en red (NAS). Existen
aceleradores hardware, usados en grandes sistema de proceso de transacciones. Los SGBD se
encuentran en el corazn de toda aplicacin que maneje datos. Los SGBD se basan en sistemas
operativos estndar para efectuar dichas funciones.
Historia[editar editar cdigo]
Las Bases de Datos han estado en uso desde los primeros das de los ordenadores electrnicos. A
diferencia de los sistemas modernos, que se pueden aplicar a datos y necesidades muy diferentes, la
mayor parte de los sistemas originales estaban enfocados a bases de datos especficas y pensados
para ganar velocidad a costa de perder flexibilidad. Los SGBD originales slo estaban a disposicin de
las grandes organizaciones que podan disponer de los complejos ordenadores necesarios.
Sistemas de navegacin de 1960[editar editar cdigo]
Segn los ordenadores fueron ganando velocidad y capacidad, aparecieron sistemas de bases de datos
de propsito general; a mediados de 1960 ya haban algunos sistemas en uso. Apareci el inters en
obtener un estndar y Charles Bachman -autor de uno de los primeros productos, el Integrated Data
Store (IDS)- fund el "Database Task Group" dentro de CODASYL, el grupo responsable de la creacin
y estandarizacin de COBOL. En 1971 publicaron su estndar, que pas a ser conocido como la
"aproximacin CODASYL", y en breve aparecieron algunos productos basados en esta lnea.
La estrategia de CODASYL estaba basada en la navegacin manual por un conjunto de datos
enlazados en red. Cuando se arrancaba la base de datos, el programa devolva un enlace al primer
registro de la base de datos, el cual a su vez contena punteros a otros datos. Para encontrar un registro
concreto el programador deba ir siguiendo punteros hasta llegar al registro buscado.
Para responder a preguntas sencillas como "buscar todas las personas en Japn" el programa deba
recorrer todos los datos para escoger los registros correctos. Esencialmente no existan los conceptos
"buscar" ni "encontrar" que sera inaceptable hoy en da, pero que en los tiempos en que los datos se
guardaban en cintas no era viable llevarlos a la prctica.
Se encontraron soluciones a muchos de esos problemas. El fabricante Prime cre un SGBD ajustado a
CODASYL basado en rboles binarios que atajaba la navegacin de registro en registro proveyendo
caminos alternativos de acceso. Tambin aportaba un lenguaje de interrogacin muy claro. De hecho no
hay razn para no poder aplicar los conceptos de normalizacin a bases de datos CODASYL, pero en
ltimo trmino CODASYL resultaba muy complejo y requera de mucho esfuerzo y prctica para producir
una aplicacin til.
IBM tambin tena su SGBD propio en 1968, conocido como IMS. Se trataba de
un software desarrollado para el programa Apolo sobre System/360. IMS tena conceptos similares a
CODASYL, pero usaba una jerarqua estricta de ordenacin de los datos, frente a la estructura en red
de CODASYL. Ambos conceptos fueron englobados posterioremnte en el concepto de Bases de Datos
de navegacin debido al modo de acceso a los datos, de hecho Bachman recibi al premio Turing en
1973 por su ponencia "El programador como navegador"
1
.
Sistemas relacionales de 1970[editar editar cdigo]
Artculo principal: Base de datos relacional


Tabla en el modelo relacional
Edgar Codd trabajaba en IBM, en una de esas oficinas perifricas que estaba dedicada principalmente
al desarrollo de discos duros. Estaba descontento con el modelo de navegacin CODASYL,
principalmente con la falta de operacin de bsqueda. En 1970 escribi algunos artculos en los que
perfilaba una nueva aproximacin que culmin en el documento "A Relational Model of Data for Large
Shared Data Banks"
2
.
En este artculo descubri un nuevo sistema para almacenar y trabajar con grandes bases de datos. En
vez de almacenar registros de tipo arbitrario en una lista encadenada como en CODASYL, la idea de
Codd era usar una "tabla" de registros de tamao fijo. Una lista encadenada tiene muy poca eficiencia al
almacenar datos dispersos donde algunos de los datos de un registro pueden dejarse en blanco. El
modelo relacional resuelve esto dividiendo los datos en una serie de tablas -o relaciones- normalizadas,
en las que los elementos optativos han sido extrados de la tabla principal para que ocupen espacio slo
si lo necesitan. En este modelo relacional los registros relacionados se enlazan con una "clave".
Un uso comn de las BASES DE DATOS puede mantener una agenda de usuarios, su nombre,
informacin de acceso, direccin y telfono. En la solucin de navegacin todos esos datos estara
localizados en un solo registro, y las caractersticas no usadas simplemente no estaran en la base de
datos. En la solucin relacional, los datos estaran normalizados en una tabla de usuario, una de
telfono y una de direccin, en la que seran aadidos registros si tuviramos que incorporar telfono y
direccin.
Reconciliar toda la informacin es la clave de este sistema. En el modelo relacional, una parte de la
informacin se usa como clave, identificando de manera biunvoca un registro concreto. Cuando se
recopila informacin acerca de un usuario, se acceder a la informacin de las tablas optativas
buscando mediante esa clave . Por ejemplo si el nombre de usuario es nico, la direccin y nmero de
telfono de ese usuario ser guardada con el nombre de usuario como clave. La recopilacin de esta
informacin en un solo registro es algo para lo que los lenguajes tradicionales no estn pensados.
As como el enfoque de navegacin requiere programas que realicen bucles para recolectar registros, el
enfoque relacional tambin los requerir. La solucin de Codd para los necesarios bucles se basa en un
lenguaje orientado a conjuntos, una sugerencia que ms tarde cristalizara en el ubicuo SQL. Plante el
uso de una rama del lgebra llamada clculo de tuplas, y demonstr que con ella se podran realizar
todas las operaciones tpicas sobre una base de datos, adems de extraer conjuntos de datos de una
forma sencilla.
El artculo de Codd cayo en manos de dos personas en Berkeley, Eugene Wong y Michael Stonebraker.
Ellos comenzaron un proyecto llamado INGRES con fondos asignados a un proyecto de base de datos
geogrfica programada por los estudiantes. Comenzando en 1973, INGRES produjo sus primeras
versiones de prueba que estuvieron listas para uso general en 1979. INGRES era muy similar aSystem
R de IBM en varios aspectos, incluyendo un lenguaje para acceso a los datos, conocido como QUEL.
Con el paso del tiempo, INGRES adopto el estndar SQL.
IBM realiz una implementacin de prueba del modelo relacional -PRTV- y una de produccin -Business
System 12- ambas descontinuadas. Honeywell escribi MRDS para Multics, y aparecen tambin dos
nuevas implementaciones: Alphora Dataphor y Rel. La mayora de las dems implementaciones de
SGBD llamados relacionales son en realidad SGBD SQL.
En la dcada de 1970, la Universidad de Michigan comenz el desarrollo del MICRO Information
Management System basado en el modelo terico de datos de D.L. Childs. Micro fue utilizado para
gestionar gran cantidad de datos en el Departamento de trabajo del gobierno US. Corra
en mainframe usando Michigan Terminal System. Estuvo en produccin hasta 1998.
Sistemas SQL de finales de la dcada 1970[editar editar cdigo]
Artculo principal: SQL
IBM comenz a trabajar a principios de 1970 en un prototipo lejnamente basado en los conceptos de
Codd llamndolo System R. La primera versin estuvo lista en 1974/5, y comenz as el trabajo en
sistemas multi-tabla, en los que los datos podan digregarse de modo que toda la informacin de un
registro (alguna de la cual es opcional) no tiene que estar almacenada en un nico trozo grande. Las
versiones multi-usuario siguientes fueron probadas por los usuarios en 1978 y 1979, tiempo por el que
un lenguaje SQL haba sido estandarizado. Las ideas de Codd se revelaron como operativas y
superiores a las de CODASYL, lanzando a IBM al desarrollo de una verdadera versin de produccin de
System R, conocido como SQL/DS, y posteriormente como Database 2 (DB2).
Muchos de los tcnicos de INGRES estaban seguros del xito comercial del sistema, y formaron sus
propias compaas para comercializar el desarrollo pero con un interfaz SQL. Sybase, Informix,NonStop
SQL y la misma INGRES se vendan como derivados del INGRES original en los aos 1980. Incluso
el SQL Server de Microsoft est basado en Sybase, y por consiguiente en INGRES. Slo Larry Ellison -
el fundador de Oracle- comenz un nuevo camino basado en el artculo de IBM sobre System R, y
aventaj a IBM sacando al mercado su primera versin en 1978.
Stonebraker aplic las lecciones de INGRES al desarrollo de una nueva base de datos -Postgres-
conocida ahora como PostgreSQL. PostgreSQL se utiliza para muchas aplicaciones crticas (los
registros de dominios .org y .info lo usan para su almacenamiento primario, as como grandes
compaas e instituciones financieras).
En Suecia, el artculo de Codd gener la base de datos Mimer SQL
3
en la universidad de Uppsala. En
1984 este proyecto se consolid en una compaa independiente. A principios de 1980, Mimer introdujo
la gestin de transacciones para dar robustez a las aplicaciones, una idea que fue recogida en muchos
otros SGBD.
Sistemas orientados a objetos de 1980[editar editar cdigo]
Artculo principal: Base de datos orientada a objetos
Durante la dcada de 1980 el auge de la programacin orientada a objetos influy en el modo de
manejar la informacin de las bases de datos. Programadores y diseadores comenzaron a tratar los
datos en las bases de datos como objetos. Esto quiere decir que si los datos de una persona estn en la
base de datos, los atributos de la persona como direccin, telfono y edad se consideran que
pertenecen a la persona, no son datos extraos. Esto permite establecer relaciones entre objetos y
atributos, ms que entre campos individuales.
Otro gran foco de atencin durante la dcada fue el incremento de velocidad y fiabilidad en el acceso.
En 1989, dos profesores de la Universidad de Wisconsin publicaron un artculo en una conferencia ACM
en el que exponan sus mtodos para mejorar las prestaciones de las bases de datos. La idea consista
en replicar la informacin importante -y ms solicitada- en una base de datos temporal de pequeo
tamao con enlaces a la base de datos principal. Esto implicaba que se poda buscar mucho ms rpido
en la base de datos pequea que en la grande. Su mejora de prestaciones llev a la introduccin de la
indizacin, incorporado en la totalidad de los SGBD.
Sistemas NoSQL de 2000[editar editar cdigo]
Artculo principal: NoSQL
El siglo XXI trajo una nueva tendencia en las bases de datos: el NoSQL. Esta tendencia introduca una
lnea no relacional significativamente diferentes de las clsicas. No requieren por lo general esquemas
fijos, evitan las operaciones join almacenando datos denormalizados y estn diseadas para escalar
horizontalmente. La mayor parte de ellas pueden clasificarse como almacenes clave-valor o bases de
datos orientadas a documentos.
Recientemente ha habido una gran demanda de bases de datos distribuidas con tolerancia a
particiones, pero de acuerdo con el teorema CAP no es posible conseguir un sistema distribuido que
simultneamente proporcione consistencia, disponibilidad y tolerancia al particionado. Un sistema
distribuido puede satisfacer slo dos de las tres restricciones a la vez. Por dicha razn muchas de las
bases de datos NoSQL usan la llamada consistencia eventual para proporcionar disponibilidad y
tolerancia al particionado, con un nivel mximo de consistencia de datos.
Entre las aplicaciones ms populares
encontramos MongoDB, MemcacheDB, Redis, CouchDB, Hazelcast, Apache Cassandra y HBase, todas
ellas de cdigo abierto.
Sistemas XML 2010[editar editar cdigo]
las Bases de Datos XML forman un subconjunto de las Bases de Datos NoSQL. Todas ellas usan el
formato de almacenamiento XML, que est abierto, legible por humanos y mquinas y ampliamente
usado para interoperabilidad.
En esta categora encontramos: BaseX, eXist, MarkLogic Server, MonetDB/XQuery, Sedna.
Componentes[editar editar cdigo]
El motor de la base de datos acepta peticiones lgicas de los otros subsistemas del SGBD, las
convierte en su equivalente fsico y accede a la base de datos y diccionario de datos en el
dispositivo de almacenamiento.
El subsistema de definicin de datos ayuda a crear y mantener el diccionario de datos y define la
estructura del fichero que soporta la base de datos.
El subsistema de manipulacin de datos ayuda al usuario a aadir, cambiar y borrar informacin
de la base de datos y la interroga para extraer informacin. El subsistema de manipulacin de datos
suele ser el interfaz principal del usuario con la base de datos. Permite al usuario especificar sus
requisitos de la informacin desde un punto de vista lgico.
El subsistema de generacin de aplicaciones contiene utilidades para ayudar a los usuarios en
el desarrollo de aplicaciones. Usualmente proporciona pantallas de entrada de datos, lenguajes de
programacin e interfaces.
El subsistema de administracin ayuda a gestionar la base de datos ofreciendo funcionalidades
como almacenamiento y recuperacin, gestin de la seguridad, optimizacin de preguntas, control
de concurrencia y gestin de cambios.
Lenguajes de modelacin[editar editar cdigo]
Toda base de datos soportada por un SGBD debe tener unos esquemas modelados adecuadamente.
Coincidiendo con la evolucin histrica de las bases de datos stas han utilizado distintos modelos. Los
SGBD esperan un modelo determinado para poder acceder de forma simple a la base de datos. Estos
modelos son:
jerrquico
en red
relacional
multidimensional
de objetos
Tambin se han utilizados listas invertidas.
Estructura jerrquica[editar editar cdigo]


Modelo de una base de datos jerrquica
La estructura jerrquica fue usada en los SGBD de los primeros mainframe. Las relaciones entre
registros forman una estructura en rbol. Esta estructura es simple pero inflexible ya que las relaciones
estn confinadas al tipo 1:n. El sistema IMS de IBM y el RDM Mobile de Raima
4
son ejemplos de bases
de datos con mltiples jerarquas sobre el mismo conjunto de datos. RDM Mobile es un nuevo diseo de
base de datos imbuida para una red de ordenadores mviles. La estructura jerrquica es usada hoy en
da para almacenar informacin geogrfica principalmente.
El modelo de base de datos jerrquica tiene un esquema en el que los datos se organizan en una
estructura arbrea. Esta estructura permite representar relaciones padre/hijo: cada padre puede tener
varios hijos, pero cada hijo ha de venir de slo un padre (las conocidas como relaciones 1:N). Todos los
atributos de un registro especfico estn asociados a un tipo de entidad. Este modelo fue creado por IBM
en 1960.
En una base de datos una entidad tipo es el trmino genrico para tabla. Cada registro individual se
representa como una fila, y cada atributo como una columna. Las entidades tipo se relacionan entre
ellas usando correspondencias 1:N.
Actualmente las bases de datos jerrquicas ms utilizadas son IMS de IBM y el Registro de Windows de
Microsoft.
Estructura en red[editar editar cdigo]
[[Fininguna restriccin.
El inventor de este modelo fue Charles Bachman, y el estndar fue publicado en 1969 por
CODASYL.le:DB red.png|thumb|Modelo de tintiva es que el esquema -visto como un conjunto de nodos
conectados por arcos- no tiene de datos en red]] Esta estructura contiene relaciones tintiva es que el
esquema -visto como un conjunto de nodos conectados por arcos- no tiene ms complejas que las
jerrquicas. Admite relaciones de cada registro con varios que se pueden seguir por distintos caminos.
En otras palabras, el modelo permite relaciones N:N.
El modelo en red est concebido como un modo flexible de representar objetos y sus relaciones. Su
cualidad dis
La estructura relacional[editar editar cdigo]
Artculo principal: Base de datos relacional


Ejemplo de tablas y relaciones
La estructura relacional es la ms extendida hoy en da. Se usa en mainframes, ordenadores medios y
micro-computadores. Almacena los datos en filas (tuplas) y columnas (atributos). Estas tablas pueden
estar conectadas entre s por claves comunes. Mientras trabajaba en IBM en 1972, E.F. Codd concibi
esta estructura. El modelo no resulta sencillo de interrogar por el usuario ya que puede requerir una
compleja combinacin de tablas.
La estructura multidimensional[editar editar cdigo]


Cubos representando 4 dimensiones en base de datos multidimensional
La estructura multidimensional tiene parecidos a la del modelo relacional, pero en vez de las dos
dimensiones filas-columnas, tiene N dimensiones. Esta estructura ofrece el aspecto de una hoja de
clculo. Es fcil de mantener y entender ya que los registros se almacenan del mismo modo como se
ven. Sus altas prestaciones han hecho de ella la base de datos ms popular para el proceso analtico de
transacciones en lnea (OLAP).
La estructura orientada a objetos[editar editar cdigo]
Artculo principal: Base de datos orientada a objetos


Ejemplo de base de datos conteniendo objetos y herencias
La estructura orientada a objetos est diseada siguiendo el paradigma de los lenguajes orientados a
objetos. De este modo soporta los tipos de datos grficos, imgenes, voz y texto de manera natural.
Esta estructura tiene gran difusin en aplicaciones web para aplicaciones multi-media.
Antes de la implantacin de los SGBD con estructura orientada a objetos, el almacenamiento de datos
multi-media se basaba en el sistema de ficheros para organizar, almacenar y procesar los datos. El
proceso de ficheros es engorroso, costoso e inflexible. La redundancia de los datos es un inconveniente
del proceso de ficheros ya que los ficheros independientes producen ficheros duplicados con su
implicacin en el espacio necesario. Otro inconveniente es la falta de integracin, y la dificultad de
mantenimiento. Esto fue encaminado aplicando la orientacin a objetos a los datos.
Lenguajes de consulta[editar editar cdigo]
Artculo principal: Lenguaje de consulta
Los lenguajes de consulta de bases de datos y de generacin de informes permiten interrogar a la base
de datos, analizar los datos y actualizarlos segn los privilegios de cada usuario. Tambin controla la
seguridad de la base de datos para prevenir accesos no autorizados que vean, borren o cambien los
datos. Mediante el uso de claves se permite el acceso a toda la base de datos o a parte de ella. A modo
de ejemplo, una base de datos de empleados puede contener todos los datos de los empleados, pero
slo un grupo de usuarios puede estar autorizado a ver las nminas mientras que otros pueden estar
autorizados a ver slo las historias laborales y los datos mdicos.
Si el SGBD proporciona un modo de acceder y actualizar la base de datos, as como de consultarla,
ste posibilitar la creacin de bases de datos personales. Sin embargo, le faltara la capacidad de dejar
trazas de las acciones o los controles necesarios que necesita la base de datos de una gran
organizacin. Estos controles estn slo disponibles cuando un conjunto de programas auxiliares
supervisan los accesos y actualizaciones de los datos.
Arquitectura[editar editar cdigo]
La arquitectura de un SGBD ha de especificar sus componentes (incluyendo su descripcin funcional) y
sus interfaces. Trata de conceptos distintos que la arquitectura de la base de datos. Los componentes
principales de un SGBD son:
Interfaces externos - Medios para comunicarse con el SGDB en ambos sentidos (E/S) y explotar a
todas sus funciones. Pueden afectar a la base de datos o a la operacin del SGBD, por ejemplo:
operaciones directas con la base de datos: definicin de tipos, asignacin de niveles de
seguridad, actualizacin de datos, interrogacin de la base de datos...
operaciones relativas a la operacin del SGBD: copia de seguridad y restauracin,
recuperacin tras una cada, monitoreo de seguridad, gestin del almacenamiento, reserva de
espacio, monitoreo de la configuracin, monitoreo de prestaciones, afinado...
los interfaces externos bien pueden ser utilizados por usuarios (p.e. administradores) o bien por
programas que se comunican a travs de un API.
Intrprete o procesador del lenguaje - La mayor parte de las operaciones se efectan mediante un
lenguaje de base de datos. Existen lenguajes para definicin de datos, manipulacin de datos (p.e.
SQL), para especificar aspectos de la seguridad y ms. Las sentencias en ese lenguaje se
introducen en el SGBD mediante el interfaz adecuado. Se procesan las expresiones en dicho
lenguaje (ya sea compilado o interpretado) para extraer las operaciones de modo que puedan ser
ejecutadas por el SGBD.
Optimizador de consultas - Realiza la optimizacin de cada pregunta y escoge el plan de actuacin
ms eficiente para ejecutarlo.
Motor de la base de datos - Realiza las operaciones requeridas sobre la base de datos, tpicamente
representndolo a alto nivel.
Mecanismo de almacenamiento - Traduce las operaciones a lenguaje de bajo nivel para acceder a
los datos. En algunas arquitecturas el mecanismo de almacenamiento est integrado en el motor de
la base de datos.
Motor de transacciones - Para conseguir correccin y fiabilidad la mayora de las operaciones
internas del SGBD se realizan encapsuladas dentro de transacciones. Las transacciones pueden
ser especificadas externamente al SGBD para encapsular un grupo de operaciones. El motor de
transacciones sigue la ejecucin de las transacciones y gestiona su ejecucin de acuerdo con las
reglas que tiene establecidas (p.e. control de concurrencia y su ejecucin o cancelacin).
Gestin y operacin de SGBD - Comprende muchos otros componentes que tratan de aspectos de
gestin y operativos del SGBD como monitoreo de prestaciones, gestin del almacenamiento,
mapas de almacenamiento...