Sistema de gestin de bases de datos

Un sistema de gestin de bases de datos (SGBD) es unconjunto de programas que permiten el almacenamiento,modicacin y extraccin de la informacin en una basede datos, adems de proporcionar herramientas para aa-dir, borrar, modicar y analizar los datos. Los usuariospueden acceder a la informacin usando herramientas es-peccas de interrogacin y de generacin de informes, obien mediante aplicaciones al efecto.Estos sistemas tambin proporcionan mtodos para man-tener la integridad de los datos, para administrar el accesode usuarios a los datos y para recuperar la informacin siel sistema se corrompe. Permiten presentar la informa-cin de la base de datos en variados formatos. La mayo-ra incluyen un generador de informes. Tambin puedenincluir un mdulo grco que permita presentar la infor-macin con grcos y tablas.Hay muchos tipos distintos segn cmo manejen los da-tos y muchos tamaos distintos de acuerdo a si operan encomputadoras personales y con poca memoria o grandessistemas que funcionan en mainframes con sistemas dealmacenamiento especiales.Generalmente se accede a los datos mediante lenguajesde interrogacin, lenguajes de alto nivel que simplicanla tarea de construir las aplicaciones. Tambin simpli-can la interrogacin y la presentacin de la informacin.Un SGBD permite controlar el acceso a los datos, asegu-rar su integridad, gestionar el acceso concurrente a ellos,recuperar los datos tras un fallo del sistema y hacer co-pias de seguridad. Las bases de datos y los sistemas parasu gestin son esenciales para cualquier rea de negocio,y deben ser gestionados con esmero.

1 Introduccin

Las bases de datos generalmente funcionan en compu-tadoras dedicadas de forma exclusiva a este campo. Porlas prestaciones requeridas, generalmente funcionan encomputadoras multiprocesador con abundante memoria.Para el almacenamiento de los datos puede contar consistemas de disco propio (DAS), puede conectarse a unared de almacenamiento (SAN) o conectarse a un siste-ma de almacenamiento en red (NAS). Existen acelerado-res hardware, usados en grandes sistema de proceso detransacciones. Los SGBD se encuentran en el corazn detoda aplicacin que maneje datos. Los SGBD se basan ensistemas operativos estndar para efectuar dichas funcio-nes.

2 HistoriaLas Bases de Datos han estado en uso desde los primerosdas de los ordenadores electrnicos. A diferencia de lossistemas modernos, que se pueden aplicar a datos y ne-cesidades muy diferentes, la mayor parte de los sistemasoriginales estaban enfocados a bases de datos especcasy pensados para ganar velocidad a costa de perder exi-bilidad. Los SGBD originales slo estaban a disposicinde las grandes organizaciones que podan disponer de loscomplejos ordenadores necesarios.

2.1 Sistemas de navegacin de 1960

Segn los ordenadores fueron ganando velocidad y capa-cidad, aparecieron sistemas de bases de datos de propsi-to general; a mediados de 1960 ya haba algunos sistemasen uso. Apareci el inters en obtener un estndar y Char-les Bachman -autor de uno de los primeros productos,el Integrated Data Store (IDS)- fund el Database TaskGroup dentro de CODASYL, el grupo responsable de lacreacin y estandarizacin de COBOL. En 1971 publica-ron su estndar, que pas a ser conocido como la apro-ximacin CODASYL, y en breve aparecieron algunosproductos basados en esta lnea.La estrategia de CODASYL estaba basada en la navega-cin manual por un conjunto de datos enlazados en red.Cuando se arrancaba la base de datos, el programa devol-va un enlace al primer registro de la base de datos, el cuala su vez contena punteros a otros datos. Para encontrarun registro concreto el programador deba ir siguiendopunteros hasta llegar al registro buscado.Para responder a preguntas simples como buscar todaslas personas en Japn el programa deba recorrer todoslos datos para escoger los registros correctos. No exis-tan los conceptos buscar ni encontrar, algo que se-ra inaceptable hoy en da, pero que en los tiempos en quelos datos se guardaban en cintas no era viable llevarlos ala prctica.Se encontraron soluciones a muchos de esos problemas.El fabricante Prime cre un SGBD ajustado a CODASYLbasado en rboles binarios que atajaba la navegacin deregistro en registro proveyendo caminos alternativos deacceso. Tambin aportaba un lenguaje de interrogacinmuy claro. De hecho no hay razn para no poder apli-car los conceptos de normalizacin a bases de datos CO-DASYL, pero en ltimo trmino CODASYL resultabamuy complejo y requera de mucho esfuerzo y prctica

1

2 2 HISTORIA

para producir una aplicacin til.IBM tambin tena su SGBD propio en 1968, conocidocomo IMS. Se trataba de un software desarrollado para elprograma Apolo sobre System/360. IMS tena conceptossimilares a CODASYL, pero usaba una jerarqua estric-ta de ordenacin de los datos, frente a la estructura enred de CODASYL. Ambos conceptos fueron englobadosposteriormente en el concepto de Bases de Datos de na-vegacin debido al modo de acceso a los datos, de hechoBachman recibi al premio Turing en 1973 por su ponen-cia El programador como navegador.[1]

2.2 Sistemas relacionales de 1970

Tabla en el modelo relacional

Edgar Codd trabajaba en IBM, en una de esas ocinasperifricas que estaba dedicada principalmente al desa-rrollo de discos duros. Estaba descontento con el modelode navegacin CODASYL, principalmente con la faltade operacin de bsqueda. En 1970 escribi algunos ar-tculos en los que perlaba una nueva aproximacin queculmin en el documento A Relational Model of Datafor Large Shared Data Banks.[2]

En este artculo descubri un nuevo sistema para alma-cenar y trabajar con grandes bases de datos. En vez dealmacenar registros de tipo arbitrario en una lista enca-denada como en CODASYL, la idea de Codd era usaruna tabla de registros de tamao jo. Una lista enca-denada tiene muy poca eciencia al almacenar datos dis-persos donde algunos de los datos de un registro puedendejarse en blanco. El modelo relacional resuelve esto di-vidiendo los datos en una serie de tablas -o relaciones-normalizadas, en las que los elementos optativos han si-do extrados de la tabla principal para que ocupen espacioslo si lo necesitan. En este modelo relacional los regis-tros relacionados se enlazan con una clave.Un uso comn de las bases de datos puede mantener unaagenda de usuarios, su nombre, informacin de acceso,direccin y telfono. En la solucin de navegacin todosesos datos estara localizados en un solo registro, y lascaractersticas no usadas simplemente no estaran en labase de datos. En la solucin relacional, los datos estarannormalizados en una tabla de usuario, una de telfono yuna de direccin, en la que seran aadidos registros situviramos que incorporar telfono y direccin.Reconciliar toda la informacin es la clave de este siste-

ma. En el modelo relacional, una parte de la informacinse usa como clave, identicando de manera biunvoca unregistro concreto. Cuando se recopila informacin acer-ca de un usuario, se acceder a la informacin de las ta-blas optativas buscando mediante esa clave. Por ejemplosi el nombre de usuario es nico, la direccin y nmerode telfono de ese usuario ser guardada con el nombrede usuario como clave. La recopilacin de esta informa-cin en un solo registro es algo para lo que los lenguajestradicionales no estn pensados.As como el enfoque de navegacin requiere programasque realicen bucles para recolectar registros, el enfoquerelacional tambin los requerir. La solucin de Codd pa-ra los necesarios bucles se basa en un lenguaje orientado aconjuntos, una sugerencia que ms tarde cristalizara enel ubicuo SQL. Plante el uso de una rama del lgebrallamada clculo de tuplas, y demonstr que con ella sepodran realizar todas las operaciones tpicas sobre unabase de datos, adems de extraer conjuntos de datos deuna forma sencilla.El artculo de Codd cayo en manos de dos personas enBerkeley, Eugene Wong y Michael Stonebraker. Elloscomenzaron un proyecto llamado INGRES con fondosasignados a un proyecto de base de datos geogrca pro-gramada por los estudiantes. Comenzando en 1973, IN-GRES produjo sus primeras versiones de prueba que es-tuvieron listas para uso general en 1979. INGRES eramuy similar a System R de IBM en varios aspectos, in-cluyendo un lenguaje para acceso a los datos, conocidocomo QUEL. Con el paso del tiempo, INGRES adoptoel estndar SQL.IBM realiz una implementacin de prueba del modelorelacional -PRTV- y una de produccin -Business System12- ambas descontinuadas. Honeywell escribi MRDSpara Multics, y aparecen tambin dos nuevas implemen-taciones: Alphora Dataphor y Rel. La mayora de las de-ms implementaciones de SGBD llamados relacionalesson en realidad SGBD SQL.En la dcada de 1970, la Universidad de Mchigan co-menz el desarrollo del MICRO Information Manage-ment System basado en el modelo terico de datos deD.L. Childs. Micro fue utilizado para gestionar gran can-tidad de datos en el Departamento de trabajo del go-bierno US. Corra en mainframe usando Michigan Ter-minal System. Estuvo en produccin hasta 1998.

2.3 Sistemas SQL de nales de la dcada1970

IBM comenz a trabajar a principios de 1970 en un pro-totipo lejanamente basado en los conceptos de Codd lla-mndolo System R. La primera versin estuvo lista en1974/5, y comenz as el trabajo en sistemas multi-tabla,en los que los datos podan digregarse de modo que todala informacin de un registro (alguna de la cual es opcio-nal) no tiene que estar almacenada en un nico trozo gran-

2.5 Sistemas NoSQL de 2000 3

de. Las versiones multi-usuario siguientes fueron proba-das por los usuarios en 1978 y 1979, tiempo por el queun lenguaje SQL haba sido estandarizado. Las ideas deCodd se revelaron como operativas y superiores a las deCODASYL, lanzando a IBM al desarrollo de una verda-dera versin de produccin de System R, conocido comoSQL/DS, y posteriormente como Database 2 (DB2).Muchos de los tcnicos de INGRES estaban seguros delxito comercial del sistema, y formaron sus propias com-paas para comercializar el desarrollo pero con un in-terfaz SQL. Sybase, Informix, NonStop SQL y la mismaINGRES se vendan como derivados del INGRES origi-nal en los aos 1980. Incluso el SQL Server de Microsoftest basado en Sybase, y por consiguiente en INGRES.Slo Larry Ellison -el fundador de Oracle- comenz unnuevo camino basado en el artculo de IBM sobre Sys-tem R, y aventaj a IBM sacando al mercado su primeraversin en 1978.Stonebraker aplic las lecciones de INGRES al desarro-llo de una nueva base de datos -Postgres- conocida ahoracomo PostgreSQL. PostgreSQL se utiliza para muchasaplicaciones crticas (los registros de dominios.org y.infolo usan para su almacenamiento primario, as como gran-des compaas e instituciones nancieras).En Suecia, el artculo de Codd gener la base de datosMimer SQL[3] en la universidad de Uppsala. En 1984 es-te proyecto se consolid en una compaa independien-te. A principios de 1980, Mimer introdujo la gestin detransacciones para dar robustez a las aplicaciones, unaidea que fue recogida en muchos otros SGBD.

2.4 Sistemas orientados a objetos de 1980

Durante la dcada de 1980 el auge de la programacinorientada a objetos inuy en el modo de manejar la in-formacin de las bases de datos. Programadores y disea-dores comenzaron a tratar los datos en las bases de datoscomo objetos. Esto quiere decir que si los datos de unapersona estn en la base de datos, los atributos de la per-sona como direccin, telfono y edad se consideran quepertenecen a la persona, no son datos extraos. Esto per-mite establecer relaciones entre objetos y atributos, msque entre campos individuales.Otro gran foco de atencin durante la dcada fue el in-cremento de velocidad y abilidad en el acceso. En 1989,dos profesores de la Universidad de Wisconsin publica-ron un artculo en una conferencia ACM en el que ex-ponan sus mtodos para mejorar las prestaciones de lasbases de datos. La idea consista en replicar la informa-cin importante -y ms solicitada- en una base de datostemporal de pequeo tamao con enlaces a la base de da-tos principal. Esto implicaba que se poda buscar muchoms rpido en la base de datos pequea que en la grande.Su mejora de prestaciones llev a la introduccin de laindizacin, incorporado en la totalidad de los SGBD.

2.5 Sistemas NoSQL de 2000El siglo XXI trajo una nueva tendencia en las bases de da-tos: el NoSQL. Esta tendencia introduca una lnea no re-lacional signicativamente diferentes de las clsicas. Norequieren por lo general esquemas jos, evitan las ope-raciones join almacenando datos denormalizados y estndiseadas para escalar horizontalmente. La mayor partede ellas pueden clasicarse como almacenes clave-valoro bases de datos orientadas a documentos.Recientemente ha habido una gran demanda de basesde datos distribuidas con tolerancia a particiones, perode acuerdo con el teorema CAP no es posible conseguirun sistema distribuido que simultneamente proporcioneconsistencia, disponibilidad y tolerancia al particionado.Un sistema distribuido puede satisfacer slo dos de lastres restricciones a la vez. Por dicha razn muchas de lasbases de datos NoSQL usan la llamada consistencia even-tual para proporcionar disponibilidad y tolerancia al par-ticionado, con un nivel mximo de consistencia de datos.Entre las aplicaciones ms populares encontramosMongoDB, MemcacheDB, Redis, CouchDB, Hazelcast,Apache Cassandra y HBase, todas ellas de cdigo abierto.

2.6 Sistemas XML 2010las Bases de Datos XML forman un subconjunto de lasBases de Datos NoSQL. Todas ellas usan el formato dealmacenamiento XML, que est abierto, legible por hu-manos y mquinas y ampliamente usado para interopera-bilidad.En esta categora encontramos: BaseX, eXist, MarkLogicServer, MonetDB/XQuery, Sedna.

3 Componentes El motor de la base de datos acepta peticiones l-gicas de los otros subsistemas del SGBD, las con-vierte en su equivalente fsico y accede a la base dedatos y diccionario de datos en el dispositivo de al-macenamiento.

El subsistema de denicin de datos ayuda a creary mantener el diccionario de datos y dene la estruc-tura del chero que soporta la base de datos.

El subsistema de manipulacin de datos ayuda alusuario a aadir, cambiar y borrar informacin dela base de datos y la interroga para extraer informa-cin. El subsistema de manipulacin de datos sueleser el interfaz principal del usuario con la base dedatos. Permite al usuario especicar sus requisitosde la informacin desde un punto de vista lgico.

El subsistema de generacin de aplicaciones con-tiene utilidades para ayudar a los usuarios en el desa-

4 4 LENGUAJES DE MODELACIN

rrollo de aplicaciones. Usualmente proporciona pan-tallas de entrada de datos, lenguajes de programa-cin e interfaces.

El subsistema de administracin ayuda a gestio-nar la base de datos ofreciendo funcionalidades co-mo almacenamiento y recuperacin, gestin de laseguridad, optimizacin de preguntas, control deconcurrencia y gestin de cambios.

4 Lenguajes de modelacinToda base de datos soportada por un SGBD debe tenerunos esquemas modelados adecuadamente. Coincidiendocon la evolucin histrica de las bases de datos stas hanutilizado distintos modelos. Los SGBD esperan un mo-delo determinado para poder acceder de forma simple ala base de datos. Estos modelos son:

Jerrquicos En red. Relacionales. Multidimensionales. De objetos.

Tambin se han utilizados listas invertidas.

4.1 Estructura jerrquica

Modelo de una base de datos jerrquica

La estructura jerrquica fue usada en los SGBD de losprimeros mainframe. Las relaciones entre registros for-man una estructura en rbol. Esta estructura es simplepero inexible ya que las relaciones estn connadas altipo 1:n. El sistema IMS de IBM y el RDM Mobile deRaima[4] son ejemplos de bases de datos con mltiplesjerarquas sobre el mismo conjunto de datos. RDM Mo-bile es un nuevo diseo de base de datos imbuida para unared de ordenadores mviles. La estructura jerrquica esusada hoy en da para almacenar informacin geogrcaprincipalmente.

El modelo de base de datos jerrquica tiene un esquemaen 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 hade venir de slo un padre (las conocidas como relaciones1:N). Todos los atributos de un registro especco estnasociados a un tipo de entidad. Este modelo fue creadopor IBM en 1960.En una base de datos una entidad tipo es el trmino ge-nrico para tabla. Cada registro individual se representacomo una la, y cada atributo como una columna. Lasentidades tipo se relacionan entre ellas usando correspon-dencias 1:N.Actualmente las bases de datos jerrquicas ms utilizadasson IMS de IBM y el Registro de Windows de Microsoft.

4.2 Estructura en red

Modelo de base de datos en red

Esta estructura contiene relaciones ms complejas que lasjerrquicas. Admite relaciones de cada registro con va-rios que se pueden seguir por distintos caminos. En otraspalabras, el modelo permite relaciones N:N.El modelo en red est concebido como un modo exi-ble de representar objetos y sus relaciones. Su cualidaddistintiva es que el esquema -visto como un conjunto denodos conectados por arcos- no tiene ninguna restriccin.El inventor de este modelo fue Charles Bachman, y el es-tndar fue publicado en 1969 por CODASYL.

4.3 La estructura relacionalLa estructura relacional es la ms extendida hoy en da.Se usa en mainframes, ordenadores medios y micro-computadores. Almacena los datos en las (tuplas) y co-lumnas (atributos). Estas tablas pueden estar conectadasentre s por claves comunes. Mientras trabajaba en IBM

5Ejemplo de tablas y relaciones

en 1972, E.F. Codd concibi esta estructura. El mode-lo no resulta sencillo de interrogar por el usuario ya quepuede requerir una compleja combinacin de tablas.

4.4 La estructura multidimensional

Cubos representando 4 dimensiones en base de datos multidimen-sional

La estructura multidimensional tiene parecidos a la delmodelo relacional, pero en vez de las dos dimensioneslas-columnas, tiene N dimensiones. Esta estructura ofre-ce el aspecto de una hoja de clculo. Es fcil de mantenery entender ya que los registros se almacenan del mismomodo como se ven. Sus altas prestaciones han hecho deella la base de datos ms popular para el proceso analticode transacciones en lnea (OLAP).

4.5 La estructura orientada a objetosLa estructura orientada a objetos est diseada siguiendoel paradigma de los lenguajes orientados a objetos. De es-te modo soporta los tipos de datos grcos, imgenes, vozy texto de manera natural. Esta estructura tiene gran difu-sin en aplicaciones web para aplicaciones multi-media.Antes de la implantacin de los SGBD con estructuraorientada a objetos, el almacenamiento de datos multi-media se basaba en el sistema de cheros para organizar,almacenar y procesar los datos. El proceso de cheros

Ejemplo de base de datos conteniendo objetos y herencias

es engorroso, costoso e inexible. La redundancia de losdatos es un inconveniente del proceso de cheros ya quelos cheros independientes producen cheros duplicadoscon su implicacin en el espacio necesario. Otro inconve-niente es la falta de integracin, y la dicultad de mante-nimiento. Esto fue encaminado aplicando la orientacina objetos a los datos.

5 Lenguajes de consultaLos lenguajes de consulta de bases de datos y de genera-cin de informes permiten interrogar a la base de datos,analizar los datos y actualizarlos segn los privilegios decada usuario. Tambin controla la seguridad de la basede datos para prevenir accesos no autorizados que vean,borren o cambien los datos. Mediante el uso de claves sepermite el acceso a toda la base de datos o a parte de ella.Amodo de ejemplo, una base de datos de empleados pue-de contener todos los datos de los empleados, pero sloun grupo de usuarios puede estar autorizado a ver las n-minas mientras que otros pueden estar autorizados a verslo las historias laborales y los datos mdicos.Si el SGBD proporciona un modo de acceder y actualizarla base de datos, as como de consultarla, ste posibilitarla creacin de bases de datos personales. Sin embargo, lefaltara la capacidad de dejar trazas de las acciones o loscontroles necesarios que necesita la base de datos de unagran organizacin. Estos controles estn slo disponiblescuando un conjunto de programas auxiliares supervisanlos accesos y actualizaciones de los datos.

6 ArquitecturaLa arquitectura de un SGBD especica sus componen-tes (incluyendo su descripcin funcional) y sus interfaces.Trata de conceptos distintos que la arquitectura de la basede datos. Los componentes principales de un SGBD son:

Interfaces externos - Medios para comunicarse conel SGDB en ambos sentidos (E/S) y explotar a todas

6 8 REFERENCIAS

sus funciones. Pueden afectar a la base de datos o ala operacin del SGBD, por ejemplo:

operaciones directas con la base de datos: de-nicin de tipos, asignacin de niveles de se-guridad, actualizacin de datos, interrogacinde la base de datos...

operaciones relativas a la operacin del SGBD:copia de seguridad y restauracin, recupera-cin tras una cada, monitoreo de seguridad,gestin del almacenamiento, reserva de espa-cio, monitoreo de la conguracin, monitoreode prestaciones, anado...

los interfaces externos bien pueden ser utiliza-dos por usuarios (p.e. administradores) o bienpor programas que se comunican a travs deun API.

Intrprete o procesador del lenguaje - La mayor par-te de las operaciones se efectan mediante un len-guaje de base de datos. Existen lenguajes para de-nicin de datos, manipulacin de datos (p.e. SQL),para especicar aspectos de la seguridad y ms. Lassentencias en ese lenguaje se introducen en el SGBDmediante el interfaz adecuado. Se procesan las ex-presiones en dicho lenguaje (ya sea compilado o in-terpretado) para extraer las operaciones de modoque puedan ser ejecutadas por el SGBD.

Optimizador de consultas - Realiza la optimizacinde cada pregunta y escoge el plan de actuacin mseciente para ejecutarlo.

Motor de la base de datos - Realiza las operacio-nes requeridas sobre la base de datos, tpicamenterepresentndolo a alto nivel.

Mecanismo de almacenamiento - Traduce las ope-raciones a lenguaje de bajo nivel para acceder a losdatos. En algunas arquitecturas el mecanismo de al-macenamiento est integrado en el motor de la basede datos.

Motor de transacciones - Para conseguir correc-cin y abilidad la mayora de las operaciones in-ternas del SGBD se realizan encapsuladas dentro detransacciones. Las transacciones pueden ser especi-cadas externamente al SGBD para encapsular ungrupo de operaciones. El motor de transacciones si-gue la ejecucin de las transacciones y gestiona suejecucin de acuerdo con las reglas que tiene esta-blecidas (p. eg., control de concurrencia y su ejecu-cin o cancelacin).

Gestin y operacin de SGBD - Comprendemuchosotros componentes que tratan de aspectos de gestiny operativos del SGBD como monitoreo de presta-ciones, gestin del almacenamiento, mapas de alma-cenamiento.

7 Vase tambin Base de datos Almacn de datos Anexo:Comparacin de sistemas administradoresde bases de datos relacionales

8 Referencias[1] Bachman, CharlesW. The programmer as navigator (en

ingls). Consultado el 17 de febrero de 2013.

[2] Codd, E.F. (1970).A Relational Model of Data for LargeShared Data Banks. In: Communications of the ACM 13(6): 377387.

[3] Mimer SQL (en ingls). Consultado el 18 de febrero de2013.

[4] Database Management System; Product Overview (eningls). Consultado el 19 de febrero de 2013.

79 Text and image sources, contributors, and licenses9.1 Text

Sistema de gestin de bases de datos Fuente: http://es.wikipedia.org/wiki/Sistema%20de%20gesti%C3%B3n%20de%20bases%20de%20datos?oldid=80240299 Colaboradores: 4lex, Riviera, Dodo, Robotico, Superzerocool, BOT-Superzerocool, Baneld, CEM-bot, Osepu,Montgomery, Rafa3040, TXiKiBoT, Netito777, Nioger, Biasoli, Cinevoro, VolkovBot, Technopat, Muro Bot, Robertorp, SieBot, Tirithel,Josefelipeic, Eduardosalg, Leonpolanco, Poco a poco, Osado, UA31, AVBOT, Angel GN, Diegusjaimes, Arjuno3, Juvalen, Luckas-bot,Centroamericano, Nallimbot, Capoquakeman, Alelapenya, SuperBraulio13, Xqbot, Jkbw, Ricardogpn, Igna, Botarel, BOTirithel, Hprme-dina, TobeBot, AnselmiJuan, Fitoschido, Leugim1972, PatruBOT, Angelito7, Humbefa, Olivares86, GrouchoBot, Savh, HRoestBot, Gri-llitus, JackieBot, Emiduronte, Agmesas, WikitanvirBot, MerlIwBot, Gblas.ivan, Nagb1992, AvocatoBot, 123xt, Vetranio, Creosota, Helmyoved, Makecat-bot, YFdyh-bot, Lufegero, Neopedo, MaKiNeoH, CarlosBeto, Erving Rousseau, Addbot, Balles2601, Aaron alex28, Flo-rengui, Egis57, Arreglaora, Sapristi1000, Alejandro Supra y Annimos: 194

9.2 Images Archivo:1tabla.png Fuente: http://upload.wikimedia.org/wikipedia/commons/6/6e/1tabla.png Licencia: CC BY-SA 3.0 Colaboradores:

Trabajo propio Artista original: Juvalen Archivo:Cubos_en_estructura_multidimensional.png Fuente: http://upload.wikimedia.org/wikipedia/commons/5/5a/Cubos_en_

estructura_multidimensional.png Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Juvalen Archivo:DB_jerarquica.png Fuente: http://upload.wikimedia.org/wikipedia/commons/e/e6/DB_jerarquica.png Licencia: CC BY-SA

3.0 Colaboradores: Trabajo propio Artista original: Juvalen Archivo:DB_red.png Fuente: http://upload.wikimedia.org/wikipedia/commons/b/b6/DB_red.png Licencia: CC BY-SA 3.0 Colaborado-

res: Trabajo propio Artista original: Juvalen Archivo:Estructura_orientada_a_objetos.png Fuente: http://upload.wikimedia.org/wikipedia/commons/6/66/Estructura_orientada_

a_objetos.png Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Juvalen Archivo:Tablas_y_estructura_relacional.png Fuente: http://upload.wikimedia.org/wikipedia/commons/3/37/Tablas_y_estructura_

relacional.png Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Juvalen

9.3 Content license Creative Commons Attribution-Share Alike 3.0

Introduccin Historia Sistemas de navegacin de 1960 Sistemas relacionales de 1970 Sistemas SQL de finales de la dcada 1970 Sistemas orientados a objetos de 1980 Sistemas NoSQL de 2000 Sistemas XML 2010

Componentes Lenguajes de modelacin Estructura jerrquica Estructura en red La estructura relacional La estructura multidimensional La estructura orientada a objetos

Lenguajes de consulta Arquitectura Vase tambin Referencias Text and image sources, contributors, and licensesTextImagesContent license