Modelo de base de datos

modelo multivalor
modelo semntico
base de datos XML
grafo etiquetado
Triplestore

1 Relaciones y funciones
Un sistema de gestin de base de datos puede implementar uno o varios modelos. La estructura ptima depende
de la natural organizacin de los datos de la aplicacin y
de los requisitos de sta, que incluyen ritmo de transacciones, abilidad, mantenibilidad, escalabilidad y coste.
La mayor parte de los sistemas de gestin de bases de datos estn construidos sobre un modelo de datos concreto,
aunque es posible que soporten ms de uno.

Composicin de cinco modelos de base de datos

Un modelo de base de datos es un tipo de modelo de

datos que determina la estructura lgica de una base de
datos y de manera fundamental determina el modo de almacenar, organizar y manipular los datos.
Entre los modelos lgicos comunes para bases de datos
se encuentran:

Sobre los distintos modelos fsicos de datos se puede implementar cualquier modelo lgico. La mayora del software de base de datos ofrece al usuario cierto control sobre la implementacin fsica, dado el impacto que tiene
en las prestaciones.

Modelo jerrquico
Modelo en red
Modelo relacional

Un modelo no es slo un modo de estructurar los datos:

tambin dene el conjunto de operaciones que se pueden
realizar con los datos. Por ejemplo el modelo relacional
dene operaciones como SELECT y JOIN. Aunque esas
operaciones no se ofrezcan explcitamente en un lenguaje
de interrogacin dado, proporcionan la base sobre la que
un lenguaje de interrogacin se disea.

Modelo entidadrelacin
Modelo entidadrelacin extendido
modelo de objetos
modelo documental
Modelo entidadatributovalor

2 Modelo chero plano

modelo en estrella
Los modelos fsicos de datos incluyen:

Flat File Model

ndice invertido
chero plano
Otros modelos lgicos pueden ser:
modelo asociativo
modelo multidimensional

Route No.

Miles

Activity

Record 1

I-95

12

Overlay

Record 2

I-495

05

Patching

Record 3

SR-301

33

Crack seal

Modelo chero plano

MODELOS TEMPRANOS

El modelo de chero plano consiste en una sola matriz e hijos estn unidos por enlaces. Todo nodo tendr una
bidimensional de elementos, donde todos los miembros lista de enlaces a sus hijos.
en una columna dada tienen valores del mismo tipo, y todos los miembros de la misma la estn relacionados entre ellos. Por ejemplo, las columnas para nombre y clave 3.2 Modelo de red
pueden ser usadas para la seguridad de un sistema; cada
la indicar el nombre y su correspondiente clave para un
Network Model
individuo. Las columnas en la tabla suelen tener un tipo
asociado, que la dene como cadena de caracteres, fecha
Preventive Maintenence
u hora, entero o nmero de coma otante. Este modelo
tabular fue el precursor del modelo relacional.
Rigid Pavement

Flexible Pavement

Modelos tempranos
Spall Repair

Joint Seal

Estos modelos que se describen a continuacin fueron

populares en las dcadas 1960-1970, pero hoy en da se
encuentran slo en sistemas heredados. Se caracterizan
Silicone Sealant
principalmente por tener caractersticas de navegacin
con fuertes conexiones entre la estructura fsica y la lgica, y poseen alta dependencia en los datos.
Modelo en red

3.1

Modelo jerrquico

Hierarchical Model
Pavement Improvement

Reconstruction

Maintenance

Rehabilitation

Routine

Corrective

Preventive

Modelo jerrquico

En un modelo jerrquico, los datos estn organizados en

una estructura arbrea (dibujada como rbol invertido o
raz), lo que implica que cada registro slo tiene un padre.
Las estructuras jerrquicas fueron usadas extensamente
en los primeros sistemas de gestin de datos de unidad
central, como el Sistema IMS por IBM, y ahora se usan
para describir la estructura de documentos XML. Esta estructura permite relaciones 1:N entre los datos, y es muy
eciente para describir muchas relaciones del mundo real:
tablas de contenido, ordenamiento de prrafos y cualquier
tipo de informacin anidada.
Sin embargo, la estructura jerrquica es ineciente para
ciertas operaciones de base de datos cuando el camino
completo no se incluye en cada registro. Una limitacin
del modelo jerrquico es su incapacidad para representar
de manera eciente la redundancia en datos.

Crack Seal

Patching

Asphalt Sealant

El modelo de red expande la estructura jerrquica, permitiendo relaciones N:N en una estructura tipo rbol que
permite mltiples padres. Antes de la llegada del modelo
relacional, el modelo en red era el ms popular para las
bases de datos. Este modelo de red (denido por la especicacin CODASYL) organiza datos que usan en dos
construcciones bsicas, registros y conjuntos. Los registros contienen campos que puede estar organizados jerrquicamente, como en el lenguaje COBOL. Los conjuntos
denen relaciones N:N entre registros: varios propietarios, varios miembros. Un registro puede ser un propietario de varios conjuntos, y miembro en cualquier nmero
de conjuntos.
El modelo en red es una generalizacin del modelo jerrquico, en tanto est construido sobre el concepto de
mltiples ramas (estructuras de nivel inferior) emanando
de uno o varios nodos (estructuras de nivel alto), mientras
el modelo se diferencia del modelo jerrquico en que las
ramas pueden estar unidas a mltiples nodos. El modelo
de red es capaz de representar la redundancia en datos de
una manera ms eciente que en el modelo jerrquico.
Las operaciones del modelo de red se realizan por de navegacin: un programa mantiene la posicin actual, y navega entre registros siguiendo las relaciones entre ellos.
Los registros tambin pueden ser localizados por valores
claves.
Aunque no es una caracterstica esencial del modelo, las
bases de datos en red implementan sus relaciones mediante punteros directos al disco. Esto da una velocidad de
recuperacin excelente, pero penaliza las operaciones de
carga y reorganizacin.

Entre los SGBD ms populares que tienen arquitectura

En la relacin Padre-hijo: El hijo slo puede tener un pa- en red se encuentran Total e IDMS. IDMS logr una imdre pero un padre puede tener mltiples hijos. Los padres portante base de usuarios; en 1980 adopt el modelo re-

3
lacional y SQL, manteniendo adems sus herramientas y La estructura bsica de datos del modelo relacional es la
lenguajes originales.
relacin (tabla), donde la informacin acerca de una deLa mayora de bases de datos orientadas a objetos (in- terminada entidad (p.e. empleado) se almacena en tutroducidas en 1990) usan el concepto de navegacin pa- plas (las), cada una con un conjunto de atributos (cora proporcionar acceso rpido entre objetos en una red. lumnas). Las columnas de cada tabla enumeran los disObjectivity/DB, por ejemplo, implementa 1:1, 1:N, N:1 y tintos atributos de la entidad (el nombre del empleado,
N:N entre distintas bases de datos. Muchas bases de datos direccin y nmero de telfono, p.e.), de modo que cada
orientadas a objetos tambin soportan SQL, combinando tupla de la relacin empleado representa un empleado
especco guardando los datos de ese empleado concreto.
as la potencia de ambos modelos.
Todas las relaciones (es decir, tablas) en una base de datos
relacional han de seguir unas mnimas reglas:

3.3

Modelo de chero invertido

1. el orden de los atributos es irrelevante

En un chero invertido o de ndice invertido, los datos
contenidos se usan como claves en una tabla de consulta
(lookup table), y los valores en la tabla se utilizan como
2. no puede haber tuplas repetidas
punteros a la localizacin de cada instancia. Esta es tambin la estructura lgica de los ndices de bases de datos
3. cada atributo slo puede tener un valor.
modernas, los cuales introducen slo el contenido de algunas columnas en esa tabla de consulta. El modelo de
chero invertido puede poner los ndices en cheros plaUna base de datos puede contener varias tablas, cada una
nos para acceder a sus registros de manera eciente.
similar al modelo plano. Una de las fortalezas del modelo
Implementaciones notables de este modelo de datos la relacional es que un valor de atributo coincidente en dos
realiz Adabas de Software AG, aparecida en 1970. Ada- registros (las) -en la misma o diferente tabla- implica
bas logr una importante base de usuarios y est sopor- una relacin entre esos dos registros. Es posible tambin
tada an hoy. En la dcada de 1980 adopt el modelo designar uno o un conjunto de atributos como clave,
relacional y SQL, manteniendo sus propias herramientas que permitir identicar de manera nica una la en una
y lenguajes.
tabla.
Dicha clave que permite identicar de manera unvoca
una la en una tabla se denomina clave primaria. Las
4 Modelo relacional
claves son habitualmente utilizadas para para combinar
datos de dos o ms tablas. Por ejemplo una tabla de empleados puede contener una columna denominada departamento"", cuyo valor coincida con la clave de una tabla denominada departamentos. Las claves son esenciales a la hora de crear ndices, que facilitan la recuperacin
rpidas de datos de tablas grandes. Una clave puede estar
formada por cualquier columna o por una combinacin
de varias columnas, denominndose clave compuesta. No
es necesario denir todas las claves por adelantado; una
El modelo relacional fue introducido por E.F. Codd columna puede usarse como clave incluso si no estaba
previsto en origen.
en 1970[1] con el objetivo de querer hacer los SGBD
ms independientes de las aplicaciones. Es un modelo Una clave que tenga un signicado en el mundo fsico (tal
matemtico denido en trminos de lgica de predi- como un nombre de persona, el ISBN de un libro o el ncados y teora de conjuntos, y se han implementado mero de serie de un coche) a veces se denomina clave
con l SGBDs para mainframe, ordenadores medios y natural. Si no existe una clave natural viable, se puede
microordenadores.
asignar un sucedneo arbitrario (como dar a una persona
Los productos referidos como base de datos relacional de un nmero de empleado). En la prctica la mayor parte
hecho implementan un modelo que es slo una aproxima- de las bases de datos tienen a la vez claves sucedneas y
cin al modelo matemtico denido por Codd. Existen naturales, dado que las claves sucedneas pueden usarse
tres trminos usados con profusin en el modelo relacio- internamente para crear enlaces ntegros entre las, miennal de bases de datos: relaciones, atributos y dominios. tras que las claves naturales tienen un uso menos able a
Una relacin equivale a una tabla con las y columnas. la hora de buscar o enlazar con otras bases de datos.
Las columnas de una relacin se llaman con rigor atri- El lenguaje de interrogacin ms comn utilizado con las
butos, y el dominio es el conjunto de valores que cada bases de datos relacionales es el Structured Query Lanatributo puede tomar.
guage (SQL).

4.1

5 MODELOS POST-RELACIONALES

Modelo Dimensional

El modelo dimensional es una adaptacin especializada

del modelo relacional usada para almacenar datos en depsitos de datos, de modo que los datos fcilmente puedan ser extrados usando consultas OLAP. En el modelo
dimensional, una base de datos consiste en una sola tabla
grande de datos que son descritos usando dimensiones y
medidas. Una dimensin proporciona el contexto de un
hecho (como quien particip, cuando y donde pas, y su
tipo). Las dimensiones se toman en cuenta en la formulacin de las consultas para agrupar hechos que estn relacionados. Las dimensiones tienden a ser discretas y son
a menudo jerrquicas; por ejemplo, la ubicacin podra
incluir el edicio, el estado y el pas. Una medida es una
cantidad que describe el dato, tal como los ingresos. Es
importante que las medidas puedan ser agregados signicativamente -por ejemplo, los ingresos provenientes de
diferentes lugares puedan sumarse.

relacionales, como por ejemplo PICK y MUMPS, razonar su esencia post-relactional.

El Resource Space Model es un modelo de datos no relacional basado en clasicacin multi-dimensional.[4]

5.1 Modelo de grafo

Las bases de datos de grafos permiten incluso una estructura ms general que una base de datos en red, cualquier
nodo puede estar conectado a cualquier otro.

5.2 Modelo multivaluados

Las bases de datos multivaluadas contienen datos arracimados, en el sentido de que pueden almacenar los datos
del mismo modo que las bases de datos relacionales, pero adems permiten un nivel de profundidad al que las
relacionales slo se pueden aproximar utilizando subtablas. Esto es prcticamente igual al modo en que XML
representa los datos, donde un campo/atributo dado puede contener mltiples valores a la vez. El multivalor se
puede considerar una forma de XML comprimida.

En una consulta (OLAP), las dimensiones y los hechos

son agrupados y aadidos juntos para crear un informe.
El modelo dimensional a menudo es puesto en prctica
sobre el modelo relacional usando un esquema de estrella,
consistiendo en una tabla que contiene los datos y tablas
circundantes que contienen las dimensiones. Dimensiones Un ejemplo puede ser una factura, la que puede ser vista
complicadas podran ser representadas usando mltiples como:
tablas, usando un esquema de copo de nieve.
1. Encabezado, una entrada por factura
Un almacn de datos (data warehouse) puede contener

mltiples esquemas de estrella que comparten tablas de

2. Detalle, una entrada por concepto
dimensin, permitindoles ser usadas juntas. El establecimiento de un conjunto de dimensiones estndar es una
En el modelo multivaluado tenemos la opcin de almaceparte importante del modelado dimensional.
nar los datos como una sola tabla (1), con tablas imbuidas
representando el detalle.
Tiene la ventaja que la correspondencia entre la factura
conceptual y la de la factura como representacin de datos es biunvoca. Esto redunda en menor nmero de lecLos productos que ofrecen un modelo de datos ms turas, menos problemas de integridad referencial y una
general que el relacional se denominan a veces post- fuerte disminucin del hardware necesario para soportar
relational.[2] Como trminos alternativos se oyen inclu- un volumen de transacciones dado.
yen bases de datos hbridas, bases de datos relacionales potenciadas con objetos entre otros. El modelo de
datos de esos productos incorpora relaciones pero no li- 5.3 Modelo orientado a objetos
mitadas por las restricciones del principio de informacin
de E.F. Codd, que requiere que toda informacin en la ba- En la dcada de 1990, el paradigma de la orientacin a
se de datos debe ser modelada en trminos de valores en objetos se aplic a las bases de datos creando un nuevo
modelo llamado base de datos orientada a objetos. Esto
relaciones nada ms[3]
tuvo el n de reducir la impedancia objeto-relacional, la
Algunas de estas extensiones al modelo relacional inte- sobrecarga de convertir la informacin de su representagran conceptos de tecnologas que preceden el modelo cin en la base de datos -como las en tablas- a su rerelacional. Por ejemplo permiten representar un grafo di- presentacin en el programa -tpicamente como objeto.
rigido con rboles en los nodos. La compaa sones im- Incluso ms, los tipos de datos usados en una aplicacin
plementa este concepto en su GraphDB.
pueden denirse directamente en la base de datos, preserAlgunos productos post-relacionales aplan los sistemas vando as la base de datos la misma integridad de datos.
relacionales con caracteriticas no relacionales. Otros Las bases de datos orientadas a objetos tambin introduhan llegado al mismo punto aadiendo caractersticas cen las ideas clave de la programacin orientada a objetos
relacionales a modelos pre-relacionales. Paradjicamen- -encapsualcin y polimorsmo- en el mundo de las bases
te esto ha permitido a productos histricamente pre- de datos.

Modelos post-relacionales

Object-Oriented Model
Object 1: Maintenance Report
Date
Activity Code
Route No.
Daily Production
Equipment Hours
Labor Hours

Object 1 Instance
01-12-01
24
I-95
2.5
6.0
6.0
Object 2: Maintenance Activity
Activity Code
Activity Name
Production Unit
Average Daily Production Rate

Modelo orientado a objetos

Se han propuesto distintos modos de almacenar objetos

en una base de datos. Algunos se han aproximado desde la
prespectiva de la programacin, haciendo los objetos manipulados por el programa persistentes. Esto tpicamente
requiere la adicin de algn tipo de lenguaje de interrogacin, ya que lo lenguajes tradicionales no tienen la posibilildad de encontrar objetos basados en su contenido.
Otros se han proximado al problema desde la prespectiva de la base de datos, deniendo un modelo orientado a
objetos para la base de datos, y deniendo un lenguaje de
programacin de dicha base de datos que permite tanto
capacidades de programacin como de interrogacin.
Las bases de datos orientadas a objetos sufren falta de estandarizacin; aunque han sido denidos estndares por
en Object Database Management Group nunca han sido implementados con generalidad suciente como para
permitir la interoperabilidad entre productos. Sin embargo, las bases de datos orientadas a objetos han sido empleadas eocazmente en distintas aplicaciones: generalmente en nichos especializados como ingeniera o biologa molecular, pero no de forma general con soporte comercial. Sin embargo algunas de las ideas que ha aportado
han sido recogidas por los fabricantes de bases de datos
relacionales y se han aplicado en extensiones al lenguaje
SQL.
Una alternativa a la traduccin entre objetos y relaciones es la de usar una librera Object-Relational Mapping
(ORM).

Referencias

[1] E.F. Codd (1970). A relational model of data for large

shared data banks. In: Communications of the ACM archive. Vol 13. Issue 6(June 1970). pp.377-387.
[2] Introducing databases by Stephen Chu, in Conrick, M.
(2006) Health informatics: transforming healthcare with
technology, Thomson, ISBN 0-17-012731-1, p. 69.
[3] Date, C. J. (1 de junio de 1999). Whens an extension
not an extension?. Intelligent Enterprise 2 (8).

[4] Zhuge, H. (2008). The Web Resource Space Model. Web

Information Systems Engineering and Internet Technologies Book Series 4. Springer. ISBN 978-0-387-72771-4.

7 TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

Text and image sources, contributors, and licenses

7.1

Text

Modelo de base de datos Fuente: http://es.wikipedia.org/wiki/Modelo%20de%20base%20de%20datos?oldid=81433669 Colaboradores:

Chobot, Baneld, Tomatejc, CEM-bot, IrwinSantos, LMLM, Technopat, Muro Bot, Jesusosm, Javierito92, Eduardosalg, Leonpolanco, Poco
a poco, Aipni-Lovrij, MastiBot, Diegusjaimes, Juvalen, SuperBraulio13, Xqbot, Jkbw, Magomaitin, Igna, Rubenval, TiriBOT, Dxtejada,
PatruBOT, Jorge c2010, Foundling, Savh, WikitanvirBot, Antonorsi, MerlIwBot, KLBot2, OsirisCk, Osboxs, Jarould, Matiia, Madai666 y
Annimos: 56

7.2

Images

Archivo:Database_models.jpg Fuente: http://upload.wikimedia.org/wikipedia/commons/3/3b/Database_models.jpg Licencia: CC BYSA 3.0 Colaboradores: Trabajo propio Artista original: Marcel Douwe Dekker
Archivo:Emp_Tables_(Database).PNG Fuente: http://upload.wikimedia.org/wikipedia/commons/8/87/Emp_Tables_%28Database%
29.PNG Licencia: Public domain Colaboradores: Trabajo propio Artista original: Jamesssss
Archivo:Flat_File_Model.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/d/dd/Flat_File_Model.svg Licencia: Public domain Colaboradores: http://commons.wikimedia.org/wiki/File:Flat_File_Model.jpg Artista original: Wgabrie (<a href='//commons.
wikimedia.org/wiki/User_talk:Wgabrie' title='User talk:Wgabrie'>talk</a>) 16:48, 13 March 2009 (UTC)
Archivo:Hierarchical_Model.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/e/eb/Hierarchical_Model.svg Licencia: Public domain Colaboradores: http://knowledge.fhwa.dot.gov/tam/aashto.nsf/All+Documents/4825476B2B5C687285256B1F00544258/
\protect\char"0024\relaxFILE/DIGloss.pdf, page 10. Artista original:
U.S. Department of Transportation
vectorization: Trabajo propio
Archivo:Network_Model.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/3/3e/Network_Model.svg Licencia: Public domain Colaboradores: Data Integration Glossary. Artista original:
U.S. Department of Transportation
vectorization: Trabajo propio
Archivo:Object-Oriented_Model.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/7/7c/Object-Oriented_Model.svg Licencia: Public domain Colaboradores: Data Integration Glossary. Artista original:
U.S. Department of Transportation
vectorization: Trabajo propio

7.3

Content license

Creative Commons Attribution-Share Alike 3.0