Modelo entidad-relación

Ir a la navegaciónIr a la búsqueda
Este artículo o sección necesita referencias que aparezcan en una publicación
acreditada.
Este aviso fue puesto el 6 de octubre de 2011.

Ejemplo de diagrama E-R

Un modelo de entidad relación es una herramienta para el modelo de datos, la cual

permite representar entidades de una Base de Datos

1. Se elabora el diagrama (o diagramas) entidad-relación.

2. Se completa el modelo con listas de atributos y una descripción de otras
restricciones que no se pueden reflejar en el diagrama.
El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas
para lograr un modelo directamente implementable en una base de datos. Brevemente:
Permite mostrar resultados entre otras entidades pertenecientes a las existentes de
manera que se encuentre la normatividad de archivos que se almacenarán.

 Transformación de relaciones múltiples en binarias.

 Normalización de una base de datos de relaciones (algunas relaciones pueden
transformarse en atributos y viceversa).
 Conversión en tablas (en caso de utilizar una base de datos relacional).

Índice

 1Base teórica y conceptual

o 1.1Entidad
o 1.2Atributos
o 1.3Conjunto de relaciones
 2Restricciones
o 2.1Correspondencia de cardinalidades
o 2.2Restricciones de participación
 3Claves
 4Diagrama entidad-relación
o 4.1Entidades
o 4.2Atributos
o 4.3Relación
 5Diagramas extendidos
o 5.1Entidades fuertes y débiles
o 5.2Cardinalidad de las relaciones
o 5.3Atributos en relaciones
o 5.4Herencia
o 5.5Agregación
 6Véase también
 7Enlaces externos

Base teórica y conceptual[editar]

El modelo de datos entidad-relación está basado en una percepción del mundo real que
consta de una colección de objetos básicos, llamados entidades, y de relaciones entre
esos objetos amorfos.
Entidad[editar]
Representa una “cosa”, "objeto" o "concepto" del mundo real con existencia independiente,
es decir, se diferencia únicamente de otro objeto o cosa, incluso siendo del mismo tipo, o
una misma entidad.
Algunos Ejemplos:

 Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
 Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos
diferentes, por ejemplo, el número de chasis).
 Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).
Una entidad puede ser un objeto con existencia física como: una persona, un animal, una
casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de
trabajo, una asignatura de clases, un nombre, etc. (entidad abstracta).
Una entidad está descrita y se representa por sus características o atributos. Por ejemplo,
la entidad Persona tiene como características: Nombre, Apellido, Género, Estatura, Peso,
Fecha de nacimiento.
Atributos[editar]
Los atributos son las características que definen o identifican a una entidad. Estas pueden
ser muchas, y el diseñador solo utiliza o implementa las que considere más relevantes.
En un conjunto de entidades del mismo tipo, cada entidad tiene valores específicos
asignados para cada uno de sus atributos, de esta forma, es posible su identificación
unívoca.
Ejemplos:
A la colección de entidades «alumnos», con el siguiente conjunto de atributos en común,
(id, nombre, edad, semestre), pertenecen las entidades:

 (1, Sophia, 15 años, 2)

 (2, Josefa, 19 años, 5)
 (3, Carlos, 20 años, 2)
 ...
Cada una de las entidades pertenecientes a este conjunto se diferencia de las demás por
el valor de sus atributos. Nótese que dos o más entidades diferentes pueden tener los
mismos valores para algunos de sus atributos, pero nunca para todos.
En particular, los atributos identificativos son aquellos que permiten diferenciar a una
instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a
un alumno de otro es su número de id.
Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que
será almacenado a restricciones en los valores que el atributo puede tomar (cadenas de
caracteres, números, solo dos letras, solo números mayores que cero, solo números
enteros...).
Cuando algún atributo correspondiente a una entidad no tiene un valor determinado, recibe
el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada
al respecto del mismo.
Conjunto de relaciones[editar]
Consiste en una colección, o conjunto, de relaciones de la misma naturaleza.
Ejemplo:
Dados los conjuntos de entidades "Habitación" y "Huésped", todas las relaciones de la
forma habitación-huésped, permiten obtener la información de los huéspedes y sus
respectivas habitaciones.
La dependencia o asociación entre los conjuntos de entidades es llamada participación.
En el ejemplo anterior los conjuntos de entidades "Habitación" y "Huésped" participan en
el conjunto de relaciones habitación-huésped.
Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades
participantes en la relación.

Restricciones[editar]
Son reglas que deben respetar las entidades y relaciones almacenadas en la base de
datos.
Correspondencia de cardinalidades[editar]
Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la
cardinalidad de la correspondencia indica el número de entidades con las que puede estar
relacionada una entidad dada.
Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, las
cardinalidades pueden ser:

 Uno a Uno: (1:1) Un registro de una entidad A se relaciona con solo un registro en
una entidad B. (ejemplo dos entidades, profesor y departamento, con llaves primarias,
código_profesor y jefe_depto respectivamente, un profesor solo puede ser jefe de un
departamento y un departamento solo puede tener un jefe).

 Uno a Varios: (1:N) Un registro en una entidad en A se relaciona con cero o muchos
registros en una entidad B. Pero los registros de B solamente se relacionan con un
registro en A. (ejemplo: dos entidades, vendedor y ventas, con llaves primarias,
código_vendedor y venta, respectivamente, un vendedor puede tener muchas ventas
pero una venta solo puede tener un vendedor).

 Varios a Uno: (N:1) Una entidad en A se relaciona exclusivamente con una entidad en
B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo
empleado-centro de trabajo).

 Varios a Varios: (N:M) Una entidad en A se puede relacionar con 0 o con muchas
entidades en B y viceversa (ejemplo asociaciones-ciudadanos, donde muchos
ciudadanos pueden pertenecer a una misma asociación, y cada ciudadano puede
pertenecer a muchas asociaciones distintas).
Restricciones de participación[editar]
Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha
participación puede ser de dos tipos:

 Total: Cuando cada entidad en A participa en al menos una relación de R.

 Parcial: Cuando al menos una entidad en A NO participa en alguna relación de R.

Claves[editar]
Es un subconjunto del conjunto de atributos comunes en una colección de entidades, que
permite identificar inequívocamente cada una de las entidades pertenecientes a dicha
colección. Asimismo, permiten distinguir entre sí las relaciones de un conjunto de
relaciones.
Dentro de los conjuntos de entidades existen los siguientes tipos de claves:

 Superclave: Es un subconjunto de atributos que permite distinguir unívocamente cada

una de las entidades de un conjunto de entidades. Si se añade un atributo al anterior
subconjunto, el resultado seguirá siendo una superclave.

 Clave candidata: Se trata de superclave mínima, es decir, cualquier subconjunto de

atributos de la misma no puede ser una superclave.

 Clave primaria: Es una clave candidata, elegida por el diseñador de la base de datos,
para identificar unívocamente las entidades en un conjunto de entidades.
Los valores de los atributos de una clave, no pueden ser todos iguales para dos o más
instancias.
Para poder distinguir unívocamente las relaciones en un conjunto de relaciones R, se
deben considerar dos casos:

 R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la

unión de las claves primarias de todos los conjuntos de entidades participantes.

 R tiene atributos asociados: En este caso, se usa como clave primaria de R la unión
de los atributos asociados y las claves primarias de todos los conjuntos de entidades
participantes.
Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria está
compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se
consideran los siguientes casos, según sus cardinalidades:

 R es de muchos a uno de A a B entonces sólo se toma la clave primaria de A, como

clave primaria de R.
 R es de uno a muchos de A a B entonces se toma sólo la clave primaria de B, como
clave primaria de R.
 R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias,
como clave primaria de R.
 R es de muchos a muchos de A a B entonces se toma la unión de los atributos que
conforman las claves primarias de A y de B, como clave primaria de R.

Diagrama entidad-relación[editar]
Anteriormente detallamos los conceptos relacionados al modelo ER, en esta sección
profundizaremos en como representarlos gráficamente. Cabe destacar que para todo
proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan
conocimiento necesario y además fundamentan nuestro modelo al momento de
presentarlo a terceros.
Formalmente, los diagramas ER son un lenguaje gráfico para describir conceptos.
Informalmente, son simples dibujos o gráficos que describen información que trata un
sistema de información y el software que lo automatiza.
Entidades[editar]
Las entidades son el fundamento del modelo entidad relación. Podemos adoptar como
definición de entidad cualquier cosa o parte del mundo que es distinguible del resto. Por
ejemplo, en un sistema bancario, las personas y las cuentas bancarias se podrían
interpretar como entidades. Las entidades pueden representar entes concretos, como una
persona o un avión, o abstractas, como por ejemplo un préstamo o una reserva. Se
representan por medio de un rectángulo. que pueden ser de tipo: maestras,
transaccionales, históricas y temporales.
Atributos[editar]
Se representan mediante un círculo o elipse etiquetado mediante un nombre en su interior.
Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta.
Por motivos de legibilidad, los atributos suelen no aparecer representados en el diagrama
entidad-relación, sino descritos textualmente en otros documentos adjuntos.
Relación[editar]
Describe cierta dependencia entre entidades o permite la asociación de las mismas.
Por ejemplo:
Si tenemos dos entidades, CLIENTE y HABITACIÓN, podemos entender la relación
entre ambas al tomar un caso concreto (ocurrencia) de cada una de ellas.
Entonces, podríamos tener la ocurrencia Habitación 502, de la
entidad HABITACIÓN y la ocurrencia Henry Johnson McFly Bogard, de la
entidad CLIENTE, entre las que es posible relacionar que la habitación 502 se
encuentra ocupada por el huésped de nombre Henry Johnson McFly Bogard.

Diagramas extendidos[editar]

DER extendido

Los diagramas Entidad-Relación no cumplen su propósito con eficacia debido a que

tienen limitaciones semánticas. Por ese motivo se suelen utilizar los diagramas
Entidad-Relación extendidos que incorporan algunos elementos más al lenguaje:
Entidades fuertes y débiles[editar]
Cuando una entidad participa en una relación puede adquirir un papel fuerte o débil.
Una entidad débil es aquella que no puede existir sin participar en la relación; es decir,
aquella que no puede ser unívocamente identificada solamente por sus atributos.
Una entidad fuerte (también conocida como entidad regular) es aquella que sí puede
ser identificada unívocamente. En los casos en que se requiera, se puede dar que una
entidad fuerte "preste" algunos de sus atributos a una entidad débil para que esta
última se pueda identificar.
Las entidades débiles se representan mediante un doble rectángulo; es decir, un
rectángulo con doble línea.
Se puede hablar de la existencia de dos tipos de dependencias en las entidades
débiles:
Dependencia por existencia
Las ocurrencias de la entidad débil pueden identificarse mediante un atributo
identificador clave sin necesidad de identificar la entidad fuerte relacionada.
Dependencia por identidad
La entidad débil no puede ser identificada sin la entidad fuerte relacionada.
(Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIÓN, para
identificar una edición necesitamos conocer el identificador del libro).
Cardinalidad de las relaciones[editar]
Cardinalidad es el número de entidades con la cual otra entidad puede asociar
mediante una relación binaria; la cardinalidad puede ser: Uno a uno, uno a
muchos ó muchos a uno y muchos a muchos. El tipo de cardinalidad se
representa mediante una etiqueta en el exterior de la relación,
respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende del
lenguaje utilizado, la que más se usa actualmente es el unificado. Otra forma
de expresar la cardinalidad es situando un símbolo cerca de la línea que
conecta una entidad con una relación:

 "0" si cada instancia de la entidad no está obligada a participar en la

relación.
 "1" si toda instancia de la entidad está obligada a participar en la relación
y, además, solamente participa una vez.
 "N" , "M", ó "*" si cada instancia de la entidad no está obligada a
participar en la relación y puede hacerlo cualquier número de veces.
(también se puede representar como M:M)

Ejemplos de relaciones que expresan cardinalidad:

 Un policía (entidad) tiene (relación) un arma (entidad) siempre y cuando

no realice funciones de oficina, pudiendo entonces tenerla o no asignada.
Es una relación 0:1.
 Cada esposo (entidad) está casado (relación) con una única esposa
(entidad) y viceversa. Es una relación 1:1.
 Una factura (entidad) se emite (relación) a una persona (entidad) y sólo
una, pero una persona puede tener varias facturas emitidas a su nombre.
Todas las facturas se emiten a nombre de alguien. Es una relación 1:N.
 Un cliente (entidad) puede comprar (relación) varios servicios (entidad) y
un servicio puede ser comprado por varios clientes distintos. Es una
relación N:M.
Atributos en relaciones[editar]
Las relaciones también pueden tener atributos asociados. Se representan
igual que los atributos de las entidades. Un ejemplo típico son las relaciones
de tipo "histórico" donde debe constar una fecha o una hora. Por ejemplo,
supongamos que es necesario hacer constar la fecha de emisión de una
factura a un cliente, y que es posible emitir duplicados de la factura (con
 distinta fecha). En tal caso, el atributo "Fecha de emisión" de la factura debería
colocarse en la relación "se emite".
Herencia[editar]
La herencia es un intento de adaptación de estos diagramas al paradigma
orientado a objetos. La herencia es un tipo de relación entre una entidad
"padre" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y
relaciones de la entidad "padre". Por tanto, no necesitan ser representadas
dos veces en el diagrama. La relación de herencia se representa mediante un
triángulo invertido interconectado por líneas a las entidades. La entidad
conectada por la parte superior del triángulo es la entidad "padre". Solamente
puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se
conectan por la parte inferior del triángulo.
Agregación[editar]

Ejemplo agregación
Es un tipo de relación dinámica, donde el tiempo de vida de una o más
entidades de bajo nivel que están incluidas en una entidad de alto nivel es
independiente a la entidad que la incluye(entidad de alto nivel).
Es una abstracción a través de la cual las relaciones se tratan como entidades
de un nivel más alto. Se utiliza para expresar relaciones entre relaciones o
entre entidades y relaciones. Se representa englobando la relación abstraída y
las entidades que participan en ella en un rectángulo. En la figura se muestra
un ejemplo de agregación en el que se representa la situación en la que un
profesor, cuando está impartiendo una clase, puede poner una incidencia
ocurrida a lo largo de ésta (se fue la luz, falta la configuración de un
determinado software, etc.).
Es una abstracción a través de la cual las relaciones se tratan como entidades de un
nivel más alto. Se utiliza para expresar relaciones entre relaciones o entre entidades
y relaciones. Se representa englobando la relación abstraída y las entidades que

Fundamentos y
participan en ella en un rectángulo.

Diseño de Bases de Datos

jueves, 20 de febrero de 2014

Modelo entidad-relación ER
El modelo entidad-relación ER es un modelo de datos que permite representar cualquier
abstracción, percepción y conocimiento en un sistema de información formado por un conjunto
de objetos denominados entidades y relaciones, incorporando una representación visual
conocida como diagrama entidad-relación.

CONCEPTOS DEL MODELO ER

Ejemplares - Conjuntos - Extensión - Instancia. Se denominan ejemplares a los registros que

guardan una serie de características similares o que pueden ser agrupados o clasificados dadas
sus características comunes en grupos bien delimitados. A los ejemplares también se los conoce
como registros de una tabla de una base de datos, o en términos de abstracción como
la extensión de la base de datos. Por ejemplo es la lista de usuarios de una biblioteca, la lista
de productos con sus características, la lista de tipos de documentos y su definición.

Entidad. La entidad es cualquier clase de objeto o conjunto de elementos presentes o no, en

un contexto determinado dado por el sistema de información o las funciones y procesos que se
definen en un plan de automatización. Dicho de otra forma, las entidades las constituyen las
tablas de la base de datos que permiten el almacenamiento de los ejemplares o registros del
sistema, quedando recogidos bajo la denominación o título de la tabla o entidad. Por ejemplo,
la entidad usuarios guarda los datos personales de los usuarios de la biblioteca, la entidad
catalogo registra todos los libros catalogados, la entidad circulación todos los libros prestados
y devueltos y así sucesivamente con todos los casos.

Atributos - Intención. Son las características, rasgos y propiedades de una entidad, que toman
como valor una instancia particular. Es decir, los atributos de una tabla son en realidad sus
campos descriptivos, el predicado que permite definir lo que decimos de un determinado
sujeto. Por ejemplo de una entidad o tabla catálogo, se pueden determinar los atributos título,
subtítulo, título paralelo, otras formas del título, autor principal, otras menciones de
responsabilidad, edición, mención de edición, editorial, lugar de publicación, fecha de
publicación,...

Relación. Vínculo que permite definir una dependencia entre los conjuntos de dos o más
entidades. Esto es la relación entre la información contenida en los registros de varias tablas.
Por ejemplo, los usuarios suelen clasificarse según una lista de tipos de usuarios, ya sean
profesores, alumnos o investigadores. De esta forma es posible emitir la relación entre el
usuario Jorge Martínez como alumno y Enrique Valtierra como profesor. Las relaciones son
definidas de forma natural en un diagrama relacional para expresar un modelo cognitivo que
dará lugar posteriormente a las interrelaciones de las entidades.

Interrelación. Las interrelaciones las constituyen los vínculos entre entidades, de forma tal
que representan las relaciones definidas en el esquema relacional de forma efectiva. Esto no
sólo la relación de los registros sino de sus tablas y de las características de la interrelación
entre las entidades, a través de un campo clave que actúa como código de identificación y
referencia para relacionar (es decir, como nexo de unión y articulación de la relación). Los
tipos de interrelaciones entre entidades o tablas se realizan aplicando las reglas de cardinalidad
y modalidad.

Entidades fuertes. Lo constituyen las tablas principales de la base de datos que contienen los
registros principales del sistema de información y que requieren de entidades o tablas auxiliares
para completar su descripción o información. Por ejemplo la tabla usuario es una entidad fuerte
en relación a la tabla tipos de usuarios, que es una entidad débil dada su condición auxiliar
para clasificar a los usuarios registrados en la biblioteca.

Entidades débiles. Son entidades débiles a las tablas auxiliares de una tabla principal a la que
completan o complementan con la información de sus registros relacionados. Por ejemplo
también son consideradas entidades débiles las tablas intermedias que sirven para compartir
información de varias tablas principales.

Modelo entidad relación Objeto de la base de datos Ejemplo

 Registros de una tabla – Conjunto de Conjunto-Usuarios{Jorge Martínez(1|alumno), Enrique
Ejemplares – Conjuntos – Extensión Valtierra(2|profesor), Miguel dos Santos(3|investigador)
registros

Entidad Tabla de la base de datos Tabla usuarios

Atributos – Intención Campos de una tabla id, nombre, apellidos, tipo de usuario, dni, dirección, telé

Relación Vínculo entre conjuntos Jorge Martínez es investigador

Interrelación Relación entre tablas Tabla Usuarios relacionada con Tabla Tipo de usuarios

Entidades fuertes Tabla principal Tabla Usuarios

Entidades débiles Tabla auxiliar Tabla Tipo de usuarios

Tabla1. Esquema con algunos elementos fundamentales del diagrama ER

Clave. Es el campo o atributo de una entidad o tabla que tiene como objetivo distinguir cada
registro del conjunto, sirviendo sus valores como datos vinculantes de una relación entre
registros de varias tablas.
 Superclave. Es la combinación de campos clave que identifican unívocamente un
registro en una tabla o entidad.
 Clave principal primaria. Permiten identificar unívocamente cada registro de una
tabla. Por ejemplo campo auto-numérico interno ID.
 Clave candidata. Campos que cumplen las condiciones de identificación única de
registros, pero que no fueron definidos como principales por el diseñador. Por ejemplo el
DOI (Document Object Identifier) es un campo que define unívocamente un registro de un
documento en una tabla o entidad concreta. No obstante a efectos de gestión interna del
sistema el campo principal ID que contiene un valor numérico correlativo, permite un
tratamiento más sencillo que el DOI.
 Clave externa. Campo clave conformado por el valor de una clave principal primaria
de otra tabla. Por ejemplo el campo id_tipodeusuario en la tabla usuarios es un campo clave
externo que guarda el valor del campo primario ID de la tabla tipodeusuario, especificando
de esa forma que un usuario como Enrique Valtierra sea de tipo 2 es decir profesor.

Integridad referencial. Se denomina integridad referencial al tipo de interrelación que se

produce entre tablas mediante un campo clave que deberá contener la cadena alfanumérica
exacta al identificador de la tabla auxiliar para poder realizar la relación entre los registros.
En caso contrario no se produce la relación. Además, se trata de un mecanismo que evita
duplicidades e incorrecciones ya que la propiedad de integridad referencial conmina a que los
datos de un usuario además de su identificador ID sean distintos al de los demás. Dicho de otra
forma, no pueden existir dos registros iguales con los mismos datos.

Tipos de relaciones
 Según cardinalidad. La cardinalidad se representan en un diagrama ER como una
etiqueta que se ubica en ambos extremos de la línea de relación de las entidades y que
puede contener diversos valores entre los que destacan comúnmente el 1 y el *, obteniendo
los siguientes tipos:
o Relación 1 a 1. La relación uno a uno, define que un único registro de la tabla
puede estar relacionado con un único registro de la tabla relacionada.
 Figura1. Esquema de relación 1 a 1

o Relación 1 a *. La relación de uno a varios, define que un registro dado de una

tabla auxiliar o secundaria sólo puede estar vinculado con un único registro de la tabla
principal con la que está relacionada.

Figura2. Esquema de relación 1 a muchos

o Relación * a *. La relación de varios a varios, define que un registro de una
tabla puede estar relacionado con varios registros de la tabla relacionada y viceversa.

Figura3. Esquema de relación muchos a muchos

 Según modalidad
o Optativa. La relación entre un registro de una tabla y varios de la tabla
relacionada, puede existir o no.
o Obligatoria. La relación entre un registro de una tabla y otro de la tabla
relacionada es obligada, debe existir siempre.

Figura4. Esquema de relaciones optativas y obligatorias

Ejemplos
Relación 1 a 1. Cada documento adquirido es registrado podría equipararse a la cardinalidad 1
a 1. Esto significa que cada documento que se introduce en el módulo de adquisiciones (y por
ende en su tabla) tiene su correspondencia con los documentos que finalmente se reciben en
la biblioteca para ser dados de alta en la tabla registro. De esta forma, puede haber o no
documentos en proceso de adquisición (relación optativa). En cambio la tabla registro se
encarga de registrar los documentos que se reciben por lo que su relación es de obligatoriedad
(todo documento registrado está presente en la tabla de adquisiciones). Todo ello no implica
que todos los documentos en fase de adquisición tengan que estar registrados. Pueden existir
documentos en fase de adquisición que no hubieran sido registrados. Véase ejemplo de
la figura5.
 Figura5. Los documentos que se adquieren son registrados

Relación 1 a *. Los usuarios de una biblioteca suelen solicitar préstamos, por lo tanto la relación
que se produce es de uno a muchos. Un usuario puede pedir o no el préstamo de uno o varios
libros o documentos. Por lo tanto, pueden existir uno o ningún usuario solicitando el préstamo,
pero para que exista la relación con la tabla préstamos, ésta debe registrar al usuario, su fecha
de préstamo y devolución. Véase figura6. Por otra parte, el préstamo se compone no sólo del
usuario que lo solicita, sino del documento u objeto que le es prestado, que es el caso que se
expone en la figura7. Al igual que en la relación del usuario con la tabla préstamo, un
documento puede o no ser prestado. Un documento puede haber sido prestado y devuelto
muchas veces y para que exista la relación entre la tabla préstamos y catálogo, debe existir un
registro que integre su información (de aquí su modalidad de relación obligatoria). Todo ello
conduce a una relación más compleja que puede observarse en la figura8. Lo que en un
principio se consideraba una relación de 1 a muchos, termina convirtiéndose en una relación
de muchos a muchos gracias a una tabla débil o intermedia que almacena la información
necesaria del usuario y del documento para poder efectuar el préstamo correspondiente. Por
lo tanto la tabla préstamos, relaciona muchos usuarios con muchos libros en múltiples conjuntos
o registros que pueden estar activos o finalizados. Recuérdese que los libros una vez devueltos
vuelven a estar disponibles para dar servicio a terceros usuarios. Por ello se concluye que para
que un préstamo tenga lugar, deberá estar presente el identificador del usuario y del
documento siendo obligatorios en todo proceso de circulación.

Figura6. Los usuarios solicitan préstamos

 Figura7. Los documentos y libros son prestados

Figura8. Lo documentos son prestados a los usuarios

Relación * a *. Cuando se catalogan los documentos en una biblioteca, al seguir las indicaciones
de las normas de catalogación, se advierte un apartado de suma importancia; las autoridades.
Éstas definen la responsabilidad intelectual, artística, cognitiva, editorial, administrativa,
introductoria, del documento. Por ello no es de extrañar que en la catalogación los campos de
autoridades sean repetibles, dado que pueden existir 1 o más autoridades. Esta relación es la
que se advierte en la figura9. Cada libro puede tener o no 1 o muchas autoridades. Por lo tanto
una autoridad puede estar presente en varios libros o formar parte de varias responsabilidades
en el mismo.
 Figura9. Los libros al ser catalogados pueden tener o no autoridades

Base de datos relacional

Ir a la navegaciónIr a la búsqueda

Véase también: Base de datos objeto-relacional

La base de datos relacional (BDR) es un tipo de base de datos (BD) que cumple con
el modelo relacional (el modelo más utilizado actualmente para implementar las BD ya
planificadas).
Tras ser postuladas sus bases en 1970 por Edgar Frank Codd,1 de los
laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo
paradigma en los modelos de base de datos.2
Un sistema de software utilizado para mantener las bases de datos relacionales es un
relational database management system (RDBMS) o sistema de gestión de bases de datos
relacionales. Virtualmente, todas los sistemas de bases de datos relacionales
utilizan SQL (Structured Query Language) para consultar y mantener la base de datos.

Índice

 1Características comunes
 2Elementos
o 2.1Relaciones (características en común)
 2.1.1Relaciones base
 2.1.2Relaciones derivadas
o 2.2Restricciones
o 2.3Dominios
o 2.4Clasificación de Claves
 2.4.1Clave primaria
 2.4.2Clave externa o foránea
 2.4.3Clave índice
 o 2.5Procedimientos almacenados
 3Estructura y definiciones
 4Manipulación de la información
 5Gestores de base de datos relacionales
 6Ventajas y desventajas
 7Diseño de las bases de datos relacionales
 8Véase también
 9Referencias
 10Enlaces externos

Características comunes[editar]
 Una base de datos se compone de varias tablas, denominadas relaciones.
 No pueden existir dos tablas con el mismo nombre ni registro.
 Cada tabla es a su vez un conjunto de campos (columnas) y registros (filas).
 La relación entre una tabla padre y un hijo se lleva a cabo por medio de las claves
primarias y claves foráneas (o ajenas).
 Las claves primarias son la clave principal de un registro dentro de una tabla y estas
deben cumplir con la integridad de datos.
 Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave
primaria del registro padre; por medio de estas se hacen las formas relacionales.

Elementos[editar]
Véase también: Dato

Relaciones (características en común)[editar]

En una BDR, todos los datos se almacenan y se accede a ellos por medio de relaciones
previamente establecidas.
Relaciones base[editar]
Las relaciones que almacenan datos son llamadas relaciones base y su implementación
es llamada "tabla".
Relaciones derivadas[editar]
Otras relaciones no almacenan datos, pero son calculadas al aplicar operaciones
relacionales. Estas relaciones son llamadas relaciones derivadas y su implementación es
llamada "vista" o "consulta". Las relaciones derivadas son convenientes, ya que expresan
información de varias relaciones actuando como si fuera una sola tabla.
Restricciones[editar]
Una restricción es una limitación que obliga el cumplimiento de ciertas condiciones en la
BD.
Algunas no son determinadas por los usuarios, sino que son inherentemente definidas por
el simple hecho de que la BD sea relacional. Algunas otras restricciones las puede definir
el usuario, por ejemplo, usar un campo con valores enteros entre 1 y 10.
Las restricciones proveen un método de implementar "reglas" en la base de datos.
Las restricciones limitan los datos que pueden ser almacenados en las tablas.
Usualmente se definen usando expresiones que dan como resultado un valor booleano,
indicando si los datos satisfacen la restricción o no.
Las restricciones no son parte informal y formal del modelo relacional, pero son incluidas
porque juegan el rol de organizar mejor los datos. Las restricciones son muy discutidas
junto con los conceptos relacionales.
Dominios[editar]
Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio
restringe los valores del atributo, puede ser considerado como una restricción.
Matemáticamente, atribuir un dominio a un atributo significa "cualquier valor de este
atributo debe ser elemento del conjunto especificado".
Distintos tipos de dominios son: enteros, cadenas de texto, fecha, no procedurales, etc.
Cada tabla puede tener uno o más campos cuyos valores identifican de forma única cada
registro de dicha tabla, es decir, no pueden existir dos o más registros diferentes cuyos
valores en dichos campos sean idénticos. Este conjunto de campos se llama clave única.
Pueden existir varias claves únicas en una determinada tabla, y a cada una de estas suele
llamársele candidata a clave primaria.
Clasificación de Claves[editar]
Clave primaria[editar]
Artículo principal: Clave primaria

Una clave primaria es una clave única (puede estar conformada por uno o más campos de
la tabla) elegida entre todas las candidatas que define unívocamente a todos los demás
atributos de la tabla para especificar los datos que serán relacionados con las demás
tablas. La forma de hacer esto (relación entre tablas) es por medio de claves foráneas.
Clave externa o foránea[editar]
Artículo principal: Clave foránea

Una clave foránea es una referencia a una clave en otra tabla, determina la relación
existente en dos tablas. Las claves foráneas no necesitan ser claves únicas en la tabla
donde están y sí a donde están referenciadas.
Por ejemplo, el código de departamento puede ser una clave foránea en la tabla de
empleados. Se permite que haya varios empleados en un mismo departamento, pero
habrá uno y solo un departamento por cada clave distinta de departamento en la tabla de
departamentos.
Clave índice[editar]
Véase también: Índice (base de datos)

Las claves índice surgen con la necesidad de tener un acceso más rápido a los datos. Los
índices pueden ser creados con cualquier combinación de campos de una tabla. Las
consultas que filtran registros por medio de estos campos, pueden encontrar los registros
de forma no secuencial usando la clave índice.
Las bases de datos relacionales incluyen múltiples técnicas de ordenamiento, cada una de
ellas es óptima para cierta distribución de datos y tamaño de la relación.
Los índices generalmente no se consideran parte de la base de datos, pues son un detalle
agregado. Sin embargo, las claves índices son desarrolladas por el mismo grupo de
programadores que las otras partes de la base de datos.
Procedimientos almacenados[editar]
Artículo principal: Procedimientos almacenados

Un procedimiento almacenado es código ejecutable que se asocia y se almacena con la

base de datos. Los procedimientos almacenados usualmente recogen y personalizan
operaciones comunes, como insertar un registro dentro de una tabla, recopilar información
estadística, o encapsular cálculos complejos. Son frecuentemente usados por un API por
seguridad o simplicidad.
Los procedimientos almacenados no son parte del modelo relacional, pero todas las
implementaciones comerciales los incluyen.

Estructura y definiciones[editar]

Terminología de una base de datos relacional: tupla, atributo y relación.

La base de datos se organiza en dos marcadas secciones; el esquema y los datos (o

instancia).
El esquema es la definición de la estructura de la base de datos y principalmente
almacena los siguientes datos:

 El nombre de cada tabla

 El nombre de cada columna
 El tipo de dato de cada columna
 La tabla a la que pertenece cada columna
Las bases de datos relacionales pasan por un proceso al que se le conoce
como normalización de una base de datos, el resultado de dicho proceso es un esquema
que permite que la base de datos sea usada de manera óptima.
Los datos o instancia es el contenido de la base de datos en un momento dado. Es en sí,
el contenido de todos los registros.
La tabla inferior resume algunos de los términos más importantes de las bases de datos
relacionales y el término SQL correspondiente(en inglés):
 Término de bases de
Término SQL Descripción
datos relacionales

Un conjunto de datos, que representa un

Fila Tupla o registro
ítem simple

Un elemento etiquetado de una tupla, p.e.

Columna Atributo o campo
"Dirección" o "Fecha de nacimiento"

Un conjunto de tuplas compartiendo los

Tabla Relación o Base relvar mismos atributos; un conjunto de filas y
columnas.

Cualquier conjunto de tuplas; un reporte o

Vista o conjunto de
Relvar derivado informe de datos de una RDBMS en
resultados
respuesta a una consulta

Manipulación de la información[editar]
Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta
con dos lenguajes formales el álgebra relacional y el cálculo relacional. El álgebra
relacional permite describir la forma de realizar una consulta, en cambio, el cálculo
relacional solo indica lo que se desea devolver.
El lenguaje más común para construir las consultas a bases de datos relacionales es
el SQL (Structured Query Language), un estándar implementado por los principales
motores o sistemas de gestión de bases de datos relacionales integradas.
En el modelo relacional los atributos deben estar explícitamente relacionados a un nombre
en todas las operaciones, en cambio, el estándar SQL permite usar columnas sin nombre
en conjuntos de resultados, como el asterisco taquigráfico ( * ) como notación de
consultas.
Al contrario del modelo relacional, el estándar SQL requiere que las columnas tengan un
orden definido, lo cual es fácil de implementar en una computadora, ya que la memoria es
lineal.
Es de notar, sin embargo, que en SQL el orden de las columnas y los registros devueltos
en cierto conjunto de resultado nunca está garantizado, a no ser que explícitamente sea
especificado por el usuario.

Gestores de base de datos relacionales[editar]

Existe un tipo de software exclusivamente dedicado a tratar con bases de datos
relacionales, conocido como Sistema de Gestión de Bases de Datos Relacionales
(SGBDR, o RDBMS del inglés Relational Database Management System), también
llamados manejadores o gestores de las BDR.
Entre los gestores actuales más populares existen3:
 Microsoft SQL Server.
 Oracle.
 DB2.
 PostgreSQL.
 MariaDB
 MySQL.
Otros

Ventajas y desventajas[editar]
Ventajas

 Provee herramientas que garantizan evitar la duplicidad de registros.

 Garantiza la integridad referencial, así, al eliminar un registro elimina todos los
registros relacionados dependientes.
 Favorece la normalización por ser más comprensible y aplicable.
Desventajas

 Presentan deficiencias con datos gráficos, multimedia, CAD y sistemas de información

geográfica.
 No se manipulan de forma manejable los bloques de texto como tipo de dato.
 Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo de
satisfacer las necesidades de las aplicaciones anteriores y así, complementar pero no
sustituir a las bases de datos relacionales.

Diseño de las bases de datos relacionales[editar]

El primer paso para crear una base de datos, es planificar el tipo de información que se
quiere almacenar en la misma, teniendo en cuenta dos aspectos: la información disponible
y la información que necesitamos.
La planificación de la estructura de la base de datos, en particular de las tablas, es vital
para la gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en
una descripción de cada uno de los campos que componen el registro y los valores o datos
que contendrá cada uno de esos campos.
Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre,
apellido, domicilio. La definición de un campo requiere: el nombre del campo, el tipo de
campo, el ancho del campo, etc.
Los registros constituyen la información que va contenida en los campos de la tabla, por
ejemplo: el nombre del paciente, el apellido del paciente y la dirección de este.
Generalmente los diferentes tipos de campos que se pueden almacenar son los siguientes:
Texto (caracteres), Numérico (números), Fecha / Hora, Lógico (informaciones lógicas
si/no, verdadero/falso, etc.), imágenes.
En resumen, el principal aspecto a tener en cuenta durante el diseño de una tabla es
determinar claramente los campos necesarios, definirlos en forma adecuada con un
nombre especificando su tipo y su longitud.

2 Bases de datos relacionales

Es el modelo más utilizado hoy en día. Una base de datos
relacional es básicamente un conjunto de tablas, similares a las tablas
de una hoja de cálculo, formadas por filas (registros) y columnas
(campos). Los registros representan cada uno de los objetos descritos
en la tabla y los campos los atributos (variables de cualquier tipo) de
los objetos. En el modelo relacional de base de datos, las tablas
comparten algún campo entre ellas. Estos campos compartidos van a
servir para establecer relaciones entre las tablas que permitan
consultas complejas (figura 90). En esta figura aparecen tres tablas
con información municipal, en la primera aparecen los nombres de
los municipios, en la segunda el porcentaje en cada municipio de los
diferentes usos del suelo y en la tercera la población en cada
municipio lo largo del siglo XX. Como campo común aparece ident,
se trata de un identificador numérico, único para cada municipio37

Figura 90: Esquema de base de datos relacional

La idea básica de las bases de datos relacionales es la existencia

de entidades (filas en una tabla) caracterizadas
por atributos (columnas en la tabla). Cada tabla almacena entidades
del mismo tipo y entre entidades de distinto tipo se
establecen relaciones38. Las tablas comparten algún campo entre
ellas, estos campos compartidos van a servir para establecer
relaciones entre las tablas. Los atributos pueden ser de unos pocos
tipos simples:

 Números enteros
 Números reales
 Cadena de caracteres de longitud variable
Estos tipos simples se denominan tipos atómicos y permiten una
mayor eficacia en el manejo de la base de datos pero a costa de
reducir la flexibilidad a la hora de manejar los elementos complejos
del mundo real y dificultar la gestión de datos espaciales, en general
suponen un problema para cualquier tipo de datos geométricos.
 Las relaciones que se establecen entre los diferentes elementos de
dos tablas en una base de datos relacional pueden ser de tres tipos
distintos:

 Relaciones uno a uno, se establecen entre una

entidad de una tabla y otra entidad de otra tabla.
Un ejemplo aparece en la figura 90.
 Relaciones uno a varios, se establecen entre varias
entidades de una tabla y una entidad de otra tabla.
Un ejemplo sería una tabla de pluviómetros en la
que se indicara el municipio en el que se
encuentra. La relación sería entre un municipio y
varios pluviómetros
 Relaciones varios a varios, se establecen entre
varias entidades de cada una de las tablas. Un
ejemplo sería una tabla con retenes de bomberos
y otra con espacios naturales a los que cada uno
debe acudir en caso de incendio.

2.1 SQL. El lenguaje de consultas para las bases de

datos relacionales
El lenguaje de consultas SQL (Lenguaje Estructurado de
Consultas) se ha convertido, debido a su eficiencia, en un estandar
para las bases de datos relacionales. A pesar de su estandarización se
han desarrollado, sobre una base común, diversas versiones
ampliadas como las de Oracle o la de Microsoft SQL server.

Es un lenguaje declarativo en el que las órdenes especifican cual

debe ser el resultado y no la manera de conseguirlo (como ocurre en
los lenguajes procedimentales). Al ser declarativo es muy
sistemático, sencillo y con una curva de aprendizaje muy agradable.
Sin embargo los lenguajes declarativos carecen de la potencia de los
procedimentales. El gran éxito de las bases de datos relacionales se
debe en parte a la posibilidad de usar este lenguaje. Incluye diversos
tipos de capacidades:

 Comandos para la definición y creación de una

base de datos (CREATE TABLE).
 Comandos para inserción, borrado o
modificación de datos (INSERT, DELETE, UPDATE).
  Comandos para la consulta de datos seleccionados
de acuerdo a criterios complejos que involucran
diversas tablas relacionadas por un campo común
(SELECT).
 Capacidades aritméticas: En SQL es posible incluir
operaciones aritméticas así como comparaciones,
por ejemplo A > B + 3.
 Funciones matemáticas (sqrt(x), cos(x)) o de
manejo de textos.
 Asignación y comandos de impresión: es posible
imprimir una tabla construida por una consulta o
almacenarla como una nueva tabla.
 Funciones agregadas: Operaciones tales como
promedio (avg), desviación típica (stddev), suma
(sum), máximo (max), etc. se pueden aplicar a las
columnas de una tabla para obtener una cantidad
única y, a su vez, incluirla en consultas más
complejas.
En una base de datos relacional, los resultados de la consulta van
a ser datos individuales, tuplas39 o tablas generados a partir de
consultas en las que se establecen una serie de condiciones basadas
en valores numéricos. Por ejemplo una típica consulta sobre una tabla
en una base de datos relacional, utilizando SQL podría ser:
SELECT id, nombre, pob1991
FROM municipios
WHERE pob1991>20000;
el resultado será una tabla en la que tendremos tres columnas (id,
nombre, poblacion) procedentes de la tabla municipios, las filas
corresponderán sólo a aquellos casos en los que la poblacion en 1991
(columna pob1991) sea mayor que 20000. En el caso de que sólo uno
de los municipios cumpliera la condición obtendríamos una sola fila
(una tupla) y en caso de que la consulta fuera:
SELECT pob1991
FROM municipios
WHERE pob1991>20000;
obtendríamos un sólo número, la población del municipio más
poblado.

2.2 SIG y bases de datos relacionales: El modelo geo-

relacional
 Lo más habitual es utilizar el SGBD para almacenar la
información temática y el SIG para la información geométrica y
topológica. Una de las funcionalidades de este modelo será el
enlazado de ambos tipos de información que se almacenana de
formas completamente diferentes. Se trata del modelo de datos geo-
relacional.

Figura 91: Esquema de base de datos geo-relacional

El mayor interés del modelo geo-relacional estará en poder lanzar

una consulta SQL y obtener una o varias entidades espacial (en lugar
de número, tabla o fila) como respuesta. Para ello debe enlazarse la
base de datos espacial (mapa vectorial) con la base de datos temática
(tablas) mediante una columna en una de las tablas de la base de
datos que contenga los mismos identificadores que las entidades en la
base de datos espacial.

Podemos pensar en un mapa vectorial como en una tabla en la que

cada registro (fila) es un objeto (polígono, linea o punto) que
contiene un campo identificador y un campo que contiene la
localización (conjunto de coordenadas X e Y de tamaño,
lógicamente, variable). El hecho de que esta información se presente
en forma de tabla o en forma de mapa es simplemente una cuestión
de conveniencia.

Si pedimos, como resultados de una consulta a la base de datos

temática, estos identificadores comunes, en realidad lo que estamos
obteniendo son objetos espaciales (polígonos en el caso de los
municipios). Los resultados de las consultas podrían presentarse de
esta manera en forma de mapa en lugar de en forma de tabla de modo
que a los diferentes polígonos se le asignarían diferentes colores en
función de que se cumpliera o no una condición, o de los valores que
adoptase una variable o índice. Por ejemplo la consulta
SELECT ident, nombre
FROM municipios
WHERE 1000*(pob1991-pob1981)/pob1981>0 AND pob1981>0;
para obtener aquellos municipios con una tasa de crecimiento de
población positiva entre 1981 y 1991 en tantos por mil, podría
representarse en un SIG tal como aparece en la figura 92.

Figura 92: Municipios con crecimiento de población positivo entre 1981 y 1991

Una consulta similar a la anterior pero estableciendo una

reclasificación por colores daría el resultado que puede verse en la
figura 93 en la que el que el color rojo indica valores mayores de 50,
el amarillo entre 30 y 50, el verde entre 20 y 30, el azul entre 10 y 20
y el blanco menor de 10.
 Figura 93: Crecimiento de población entre 1981 y 1991

En estos casos se necesita un módulo específico que transforme

los resultados de las consultas en una serie de reglas para pintar los
polígonos asignando al mismo tiempo una paleta de colores definida
por el usuario.

En definitiva la única diferencia entre el trabajo de un gestor

tradicional de bases de datos y el enlace de un SIG a base de datos es
el modo de presentación (tabla o mapa). Casi todo el trabajo lo hace
el gestor de bases de datos y el Sistema de Información Geográfica,
se limita a presentar los resultados.

Hasta ahora lo que hemos hecho es obtener objetos espaciales

como resultado de una consulta, pero cuando se trabaja con un SIG
enlazado a una base de datos, se pretende que las consultas incluyan
tambien condiciones espaciales. Incluso deberíamos ser capaces de
llevar a cabo consultas interactivas en las que las condiciones se
formulan en función de donde haya pinchado el usuario en un mapa
mostrado en pantalla.

Sin embargo en el modelo geo-relacional toda la información

geométrica y topológica está en el SIG no en el SGBD por tanto las
consultas deberán preprocesarse y postprocesarse.

Preprocesamiento significa que el módulo encargado de

construir de forma automática consultas SQL como las que hemos
visto antes, y lanzarlas al programa servidor de bases de datos,
deberá hacerlo teniendo en cuenta una serie de criterios espaciales
 definidos por el usuario. Por ejemplo, si el usuario pincha en la
pantalla dentro de un polígono esperando obtener nombre y
población del municipio, el módulo deberá determinar de que
polígono se trata e incluir su identificador, por ejemplo 17, como
condición que debe cumplirse:
SELECT nombre, pob1991
FROM municipios
WHERE id==17;
Postprocesamiento implica que los resultados de la consulta SQL
deberán filtrarse para determinar cuales cumplen determinadas
condiciones relacionada con el espacio. Para ello, una de las
columnas pedidas en la consulta ha de ser el identificador a partir del
cual se obtiene, ya en el SIG, la geometría del polígono a la que se
puede aplicar la operación de análisis espacial (distancia, cruce,
inclusión, adyacencia, etc.) necesaria para derminar si se cumple o no
la condición. Aquellos casos en los que si se cumple constituye la
salida del módulo, el resto se deshechan.

NoSQL
Ir a la navegaciónIr a la búsqueda
En informática, NoSQL (a veces llamado "no sólo SQL") es una amplia clase de sistemas
de gestión de bases de datos que difieren del modelo clásico de SGBDR (Sistema de
Gestión de Bases de Datos Relacionales) en aspectos importantes, siendo el más
destacado que no usan SQL como lenguaje principal de consultas. Los datos almacenados
no requieren estructuras fijas como tablas, normalmente no soportan operaciones JOIN, ni
garantizan completamente ACID (atomicidad, consistencia, aislamiento y durabilidad) y
habitualmente escalan bien horizontalmente. Los sistemas NoSQL se denominan a veces
"no sólo SQL" para subrayar el hecho de que también pueden soportar lenguajes de
consulta de tipo SQL.
Por lo general, los investigadores académicos se refieren a este tipo de bases de
datos como almacenamiento estructurado, término que abarca también las bases de datos
relacionales clásicas. A menudo, las bases de datos NoSQL se clasifican según su forma
de almacenar los datos, y comprenden categorías como clave-valor, las implementaciones
de BigTable, bases de datos documentales, y bases de datos orientadas a grafos.
Los sistemas de bases de datos NoSQL crecieron con las principales redes sociales, como
Google, Amazon, Twitter y Facebook. Estas tenían que enfrentarse a desafíos con el
tratamiento de datos que las tradicionales SGBDR no solucionaban {ver articulo}. Con el
crecimiento de la web en tiempo real existía una necesidad de proporcionar información
procesada a partir de grandes volúmenes de datos que tenían unas estructuras
horizontales más o menos similares. Estas compañías se dieron cuenta de que el
rendimiento y sus propiedades de tiempo real eran más importantes que la coherencia, en
la que las bases de datos relacionales tradicionales dedicaban una gran cantidad de
tiempo de proceso[cita requerida].
En ese sentido, a menudo, las bases de datos NoSQL están altamente optimizadas para
las operaciones recuperar y agregar, y normalmente no ofrecen mucho más que la
funcionalidad de almacenar los registros (p.ej. almacenamiento clave-valor). La pérdida de
flexibilidad en tiempo de ejecución, comparado con los sistemas SQL clásicos, se ve
compensada por ganancias significativas en escalabilidad y rendimiento cuando se trata
con ciertos modelos de datos.[cita requerida]
 Índice

 1Historia del término

 2Arquitectura
 3Ventajas
 4Desventajas
 5Sistemas
o 5.1Tabla Comparativa de SGBD NoSQL
o 5.2Bases de datos documentales
o 5.3Bases de datos en grafo
o 5.4Bases de datos clave/valor
o 5.5Bases de datos multivalor
o 5.6Bases de datos orientadas a objetos
o 5.7Bases de datos tabular
o 5.8Bases de datos de arrays
 6Referencias
 7Enlaces externos

Historia del término[editar]

Carlo Strozzi usó el término NoSQL en 1998 para referirse a su base de datos. Era una
base de datos open-source, ligera, que no ofrecía un interface SQL, pero sí seguía el
modelo relacional1 (Strozzi sugiere que, ya que el actual movimiento NoSQL "Se sale
completamente del modelo relacional, debería, por tanto, haberse llamado 'NoREL', o algo
así.")2
Eric Evans, un empleado de Rackspace, reintrodujo el término NoSQL cuando Johan
Oskarsson de Last.fm quiso organizar un evento para discutir bases de datos distribuidas
de código abierto. El nombre intentaba recoger el número creciente de bases de datos no
relacionales y distribuidas que no garantizaban ACID, atributo clave en las SGBDR
clásicas.

Arquitectura[editar]
Típicamente las bases de datos relacionales modernas han mostrado poca eficiencia en
determinadas aplicaciones que usan los datos de forma intensiva, incluyendo el indexado
de un gran número de documentos, la presentación de páginas en sitios que tienen gran
tráfico, y en sitios de streaming audiovisual. Las implementaciones típicas de SGBDR se
han afinado o bien para una cantidad pequeña pero frecuente de lecturas y escrituras o
para un gran conjunto de transacciones que tiene pocos accesos de escritura. Por otro
lado NoSQL puede servir gran cantidad de carga de lecturas y escrituras.
Implementaciones de NoSQL usadas en el mundo real incluyen los 3TB de los marcadores
verdes de Digg (indicados para señalar las historias votadas por otros en la red social;
aunque duró menos de 3 meses y fue abandonado); los 6 TB de la base de datos del
“ENSEMBLE” de la Comisión Europea usado en los modelos de comparación y calidad del
aire, y los 50 TB de la búsqueda de la bandeja de entrada de Facebook.
Las arquitecturas NoSQL frecuentemente aportan escasas garantías de consistencia, tales
como consistencia de eventos o transaccional restringida a ítems únicos de datos. Algunos
sistemas, sin embargo, aportan todas las garantías de los sistemas ACID en algunas
instancias añadiendo una capa intermedia (como por ejemplo, AppScale o CloudTPS). Hay
dos sistemas que han sido desplegados y que aportan aislamiento snapshot para
almacenamientos de columna: El sistema Percolator de Google (basado en el sistema
BigTable) y el sistema transaccional de Hbase desarrollado por la universidad de Waterloo.
Estos sistemas, desarrollados de forma independiente, usan conceptos similares para
conseguir transacciones ACID distribuidas de múltiples filas con garantías de aislamiento
snapshot para el sistema subyacente de almacenamiento en esa columna, sin sobrecarga
extra en la gestión de los datos, despliegue en el sistema de middleware, ni mantenimiento
introducido por la capa de middleware.
Bastantes sistemas NoSQL emplean una arquitectura distribuida, manteniendo los datos
de forma redundante en varios servidores, usando frecuentemente una tabla hash
distribuida. De esta forma, el sistema puede realmente escalar añadiendo más servidores,
y el fallo en un servidor puede ser tolerado.
Algunos defensores de NoSQL promueven interfaces simples tales como los arrays
asociativos o los pares clave-valor. Otros sistemas, tales como las bases de datos nativas
en XML, promueven el soporte del estándar Xquery. Los sistemas más novedosos tales
como CloudTPS también soportan unión de queries.

Ventajas[editar]
 Estos sistemas responden a las necesidades de escalabilidad horizontal que tienen
cada vez más empresas.3
 Pueden manejar enormes cantidades de datos.
 No generan cuellos de botella.
 Escalamiento sencillo.
 Diferentes DBs NoSQL para diferentes proyectos.
 Se ejecutan en clusters de máquinas baratas.

Desventajas[editar]
Existen desacuerdos sobre la neutralidad en el punto de vista de la versión
actual de este artículo o sección.
En la página de discusión puedes consultar el debate al respecto.

 Las bases de datos NoSQL al ser de código abierto poseen un soporte diferente al
soporte que ofrecen las compañías comerciales a sus productos. Esto puede
presentar algunas ventajas y también algunas desventajas.

 Algunos productos pueden no estar lo suficientemente maduros para algunas

empresas.- A pesar de sus puestas en práctica en algunas grandes empresas, las
bases de datos NoSQL aún se enfrentan a un problema de credibilidad importante con
muchas empresas. Los críticos señalan la falta de madurez de NoSQL y los posibles
problemas de inestabilidad, mientras que citan la madurez, y una gran funcionalidad y
estabilidad de los SGBDRes. No obstante en desarrollos de sistemas al disponer del
código fuente este se puede ajustar y amoldar a las necesidades concretas de cada
empresa.

 Limitaciones de Inteligencia de Negocios.- Hay una o dos cuestiones acerca de las

capacidades de BI de las bases de datos NoSQL. ¿Pueden estas bases de datos
proporcionar la clase de minería de datos rigurosos que las empresas se utilizan con
las SGBDRes? ¿Cuántos conocimientos de programación se necesitan para hacer la
consulta ad hoc y análisis?. Las respuestas no son precisamente positivas. Las bases
de datos NoSQL no tienen muchos ganchos para el uso general de herramientas de
BI, mientras que la más simple consulta ad-hoc y análisis implica conocimientos de
programación bastante buenos. Sin embargo, las soluciones están disponibles. Quest
Software, por ejemplo, ha creado Toad para bases de datos en la nube, que
proporciona capacidades de consulta ad-hoc para algunas bases de datos NoSQL.
 La falta de experiencia.- La novedad de NoSQL significa que no hay una gran cantidad
de desarrolladores y administradores que conocen la tecnología -lo que hace difícil a
las empresas encontrar personas con los conocimientos técnicos apropiados. Por el
contrario, el mundo SGBDR tiene miles de personas muy cualificadas.

 Problemas de compatibilidad.- A diferencia de las bases de datos relacionales, que

comparten ciertos estándares, las bases de datos NoSQL tienen pocas normas en
común. Cada base de datos NoSQL tiene su propia API, las interfaces de consultas
son únicas y tienen peculiaridades. Esta falta de normas significa que es imposible
cambiar simplemente de un proveedor a otro, por si no quedara satisfecho con el
servicio.

Sistemas[editar]
Tabla Comparativa de SGBD NoSQL[editar]

Nombre Descripción

Base de datos creada por Apache del tipo clave-valor. Dispone de un lenguaje propio
para realizar consultas CQL (Cassandra Query Language). Cassandra es una
Cassandra
aplicación Java por lo que puede correr en cualquier plataforma que cuente con
la JVM. Es multiplataforma.

Base de datos creada por Salvatore Sanfilippo y Pieter Noordhuis y está apoyado
por VMWare. Se trata de una base de datos del tipo clave-valor. Se puede imaginar
como un array gigante en memoria para almacenar datos, datos que pueden ser
cadenas, hashes, conjuntos de datos o listas. Tiene la ventaja de que sus
operaciones son atómicas y persistentes. Sin embargo, Redis no permite realizar
Redis
consultas, sólo se puede insertar y obtener datos, además de las operaciones
comunes sobre conjuntos (diferencia, unión e inserción). Creado en ANSI C, por lo
tanto, es compatible y funciona sin problemas en sistemas Unix, Linux y sus
derivados, Solaris, OS/X, sin embargo no existe soporte oficial para
plataformas Windows.

Base de datos creada por MongoDB Inc. (anteriormente 10gen) del tipo orientada a
documentos, de esquema libre, es decir, que cada entrada puede tener un esquema
de datos diferente que nada tenga que ver con el resto de registros almacenados. Es
bastante rápido a la hora de ejecutar sus operaciones ya que maneja datos binarios.
En poco tiempo, MongoDB se ha convertido en una de las bases de datos NoSQL
MongoDB
favoritas por los desarrolladores. Está escrito en lenguaje C++. Para el
almacenamiento de la información, utiliza un sistema propio de documento
conocido con el nombre BSON, que es una evolución del formato JSON pero con la
peculiaridad de que puede almacenar datos representados de forma binaria. Está
disponible para los sistemas operativos Windows, Linux, OS/X y Solaris.

CouchDB Sistema creado por Apache y escrito en el lenguaje Erlang que funciona en la
mayoría de sistemas POSIX (multiplataforma), incluyendo GNU/Linux y OS/X,
 además de sistemas Windows. Como características más importantes cabe destacar
el uso de RESTful HTTP API como interfaz y JavaScript como principal lenguaje de
interacción. Para el almacenamiento de los datos se utilizan archivos JSON. Permite
la creación de vistas, que son el mecanismo que permite la combinación de
documentos para retornar valores de varios documentos, es decir, CouchDB permite
la realización de las operaciones JOIN típicas de SQL.

Bases de datos documentales[editar]

Artículo principal: Base de datos documental

 CouchDB, de Apache CouchDB

 MongoDB, de 10gen
 RavenDB, de Hibernating Rhinos.
 BaseX
 djondb
 eXist
 SimpleDB, de Amazon
 IBM Lotus Domino
 Terrastore
Bases de datos en grafo[editar]
Artículo principal: Base de datos orientada a grafos

 Neo4j
 DEX/Sparksee
 AllegroGraph
 OrientDB
 InfiniteGraph
 Sones GraphDB
 InfoGrid
 HyperGraphDB
Bases de datos clave/valor[editar]
Artículo principal: Base de datos clave-valor

 Cassandra, de Apache The Apache Cassandra

 BigTable, de Google
 Dynamo, de Amazon
 Project Voldemort, de LinkedIn
 Riak
 Redis
 Oracle NoSQL [1]
Bases de datos multivalor[editar]
Artículo principal: Base de datos multivalor

 Rocket D3 DBMS
 Rocket mvBase DBMS
 Rocket U2 Universe
 Rocket U2 Unidata
 OpenQM
 Caché InterSystems
 Reality
 Jbase
 OpenInsight
 Extensible storage engine
Bases de datos orientadas a objetos[editar]
Artículo principal: Base de datos orientada a objetos

 ObjectDB
 Zope Object Database
 ZooDB
 db4o
 GemStone S
 Objectivity/DB
 Realm.io
Bases de datos tabular[editar]

 HBase, de Apache
 BigTable, de Google
 LevelDB, versión abierta de BigTable
 Hypertable
Bases de datos de arrays[editar]

 SciDB, de Paradigm4