MODELADO DE BASES DE DATOS ORIENTADOS A GRAFOS

Vista previa del material en texto

BASES DE DATOS ORIENTADA A GRÁFOS (BDOG). BASES DE DATOS NO RELACIONAL.
Una base de datos orientada a grafos (BDOG) representa la información como nodos de un grafo y sus relaciones con las aristas del mismo, de manera que se pueda usar teoría de grafos para recorrer la base de datos ya que esta puede describir atributos de los nodos (entidades) y las aristas (relaciones).
Las bases de datos orientadas a grafos o BDOG tiene su principal característica en que representan la información en vértices y aristas cumpliendo con la disciplina matemática de la Teoría de Grafos.
Un grafo estará compuesto por dos elementos: los nodos (vértices) y las relaciones (aristas). Un nodo representa una entidad, en el que almacenaremos piezas de datos o atributos de tipo clave-valor, mientras que las relaciones representan cómo se conectan y se asocian dos nodos.
En algunos fabricantes de motores de BDOG podremos guardar datos y establecer etiquetas en las propias relaciones que nos servirá a posterior en las consultas que realicemos para poder filtrar o buscar información.
"Con la base de datos de tipo grafo podríamos demostrar el concepto teórico de los Seis grados de separación"
Las BDOG pertenecen al grupo de las NoSQL y dentro del teorema de CAP las podríamos englobar dentro de CA (Consistency, Availability) o PA (Partitioning, Availability). Esto puede generar algo de controversia, más adelante veremos los motivos de esta doble asignación.
Las clasificamos como NoSQL por las siguientes características:
· No utilizan un modelo relacional
· Carece de un esquema fijo, podemos tener nodos con diferente número de atributos.
· Mantienen la disponibilidad y acceso de la información
· Son buenas en modelos en cluster
Sus características principales son:
· Son multidimensionales, pueden almacenar atributos de diverso tamaño en los nodos
· Las relaciones pueden almacenar atributos
· Las relaciones pueden ser sin dirección, unidireccionales y bidireccionales lo que puede convertir la representación a grafos dirigidos, muy útiles en el cálculo de caminos.
· Tienen alto rendimiento en la búsqueda de resultados y sobre todo en la búsqueda de caminos.
Las BDOG están pensadas para aquellos ámbitos en donde es importante mantener un modelo extenso y amplio de la relación de la información a la vez que un esquema flexible de los datos. Podemos ver un ejemplo claro en las redes sociales, como Twitter o Facebook, donde tenemos el número de conexiones como las relaciones con nosotros y las personas como nodos del grafo.
“Las bases de datos de grafos no son nuevas, pero solventan un problema subyacente de las documentales”
Podríamos pensar que existen otros tipos de bbdd NoSQL que podrían perfectamente cumplir con las mismas características de un modelo flexible de datos, alta capacidad y velocidad en el tratamiento de la velocidad, como son las documentales, pero que al profundizar en su uso, rápidamente nos daremos cuenta de un problema y es que las bbdd NoSQL Documentales no son buenas en mantener las relaciones de información entre los documentos. Al final, las documentales realizan un encapsulamiento de su API para poder solucionar este problema, caso que ocurre con MongoDB y su “Document Reference” ($refID) que no es más que una referencia a un Embedded Document que apunta a Índice de un bloque de punteros interno.
Por este motivo, si tenemos un modelo de relaciones fuertes, o necesitamos recorrer relaciones de referencias, es más recomendable usar las bases de datos de tipo grafo.
A continuación vamos a indicar algunos de los contextos en los que podemos utilizar a las BDOG:
Árboles jerárquicos en estructuras organizativas de empresas, donde existen estructuras en forma de árbol de los departamentos y las empleados que trabajan en estos. Usando algoritmos de BFS, DFS, podemos encontrar relaciones de profundidad y anchura entre empleados y departamentos en los que trabaja o trabajó.
Sistemas de recomendación, para tiendas, donde un cliente tiene una compra pendiente de un producto, y por relación de similitud o proximidad de productos te ofrece otros para completar el pedido. Por ejemplo: quiero comprar gel de ducha y el sistema me recomienda que también compre un champú. Esto se consigue gracias a que entre ambos productos existe una o varias relaciones.
Cálculo de rutas en logística, son capaces de aplicar el algoritmo del camino más corto, usando algoritmos de Kruskal, Dijkstra o Prim. Lo que le facilita a la empresa el cálculo y reducción de costes en la selección de las rutas.
Detección del fraude, es difícil ver en una maraña de empresas por donde circula el dinero, sobre todo si se usan empresas pantalla o empresas en paraísos fiscales, testaferros, sociedades, etc. Al final tenemos un conjunto de datos de diferentes fuentes pero con relaciones directas o indirectas dificultando el seguimiento del dinero y por tanto ocultando el fraude.
Relaciones sociales, donde mayor uso se le puede dar y en donde mejor encajan.
Modelos de redes, donde una red de sistemas o computadoras puede ser representado por un grafo.
Para finalizar podemos pensar en soluciones aún más complejas, utilizadas en la área de la investigación genética y la existencia relacional directa entre las enfermedades y la genealogía.
MODELADO DE BASES DE DATOS ORIENTADOS A GRAFOS. 
En el caso del modelo de grafos, cada clase representa un nodo del grafo y cada nodo heredará un concepto del meta-modelo físico y respeta sus relaciones. Las propiedades de las clases nodo, pueden contener una, o varias, o todas las de las clases del meta-modelo físico. El siguiente modelo muestra lo descrito anteriormente, el ejemplo del grafo producido por el meta-modelo. Si se utiliza un diagrama de objetos de UML (UML object diagram) los objetos del diagrama son instancias de las clases del meta-modelo físico.
PROCESO.
1. Elaborar los objetos de datos.
2. Elaborar los diagramas de objetos.
3. Elaborar el grafo.
4. Elaborar el meta-modelo conceptual.
5. Elaborar el meta-modelo lógico/físico.
Ejemplo de objeto de datos:
Especificación de los atributos por objeto de datos: 
Profesor: nombre + cedula de identidad + apellidos + Edo_profesor + código_asignatura.
Estudiante: nombre + apellido + cedula_estudiante + jerarquía + componente + orden_de_mérito + mención + sección + año + motivo + Edo_estudiante.
Asignatura: nombre + unidad_crédito.
Corte: nro_corte + evaluación_1 + fecha_1 + %_evaluación_1 + evaluación_2 + fecha_2 + %_evaluación_2 + definitiva_1er_corte + evaluación_3 + fecha_3 + %_evaluación_3 + evaluación_4 + fecha_4 + %_evaluación_4 + definitiva_2do_corte + evaluación_5 + fecha_5 + %_evaluación_5 + evaluación_6 + fecha_6 + %_evaluación_6 + definitiva_3er_corte + calificación_final.
Trayecto: periodo_lectivo + promoción + mención + sección + nro_trayecto.
A cada uno de estos objetos de datos identificados se le asignaron sus atributos, que con la ayuda de las entrevistas a los actores, los casos de uso y los diagramas de canal y formatos obtuvimos dicha información.
DIAGRAMA DE OBJETOS DE DATOS.
Utilizando la notación UML, el objeto de datos tendría el siguiente diagrama o caja: 
 (
ASIGNATURA.
Nombre, unidad_crédito
) (
PROFESOR
Nombre, 
apellidos,
 Cedula de identidad, 
Edo_profesor
, Código_asignatura.
)
 (
CLAVE.
Nombre, cedula, correo_electrónico, nivel
)
 (
CORTE.
Nro_corte, Evaluación_1, fecha_1, %_evaluación_1, evaluación_2, fecha_2, %_evaluación_2, definitiva_1er_corte, evaluación_3 + fecha_3, %_evaluación_3, evaluación_4, fecha_4, %_evaluación_4, definitiva_2do_corte, evaluación_5, fecha_5 + %_evaluación_5, evaluación_6, fecha_6, %_evaluación_6, definitiva_3er_corte, calificación_final.
)
 (
TRAYECTO
periodo_lectivo, promoción, nro_trayecto.
)
 (
CADETE.
Nombre, apellido, cédula_estudiante, jerarquía, componente, orden_de_mérito, mención, sección, año, motivo, Edo_estudiante.
)
 
DISEÑO DEL GRAFO.
 (
T
) (
P
)
 (
A
) (
C
)
 (
E
)
META-MODELO CONCEPTUAL.
 (
TRAYECTO) (
M
U
CHOS
N
) (
UN
) (
UN
)
 (
MUCHOS
) (
ASIGNATURA
) (
PROFESOR
)
 (
U
N
) (
UN
) (
UN
)
 (
MUCHOS
) (
MUCHAS
)
 (
MUCHOS
) (
M
U
CH
A
S
) (
ESTÁ EN
) (
MUCHOS
)
 (
UN
) (
CORTE
) (
ESTUDIANTE
)
 (
MUCHOS
) (
UNA
)
 (
MUCHOS
) (
MUCHOS
)
 (
MUCHOS
) (
VARIOS
)
META-MODELO LÓGICO/FÍSICO.
 (
1
) (
1..*
) (
TRAYECTO
)
 (
1
) (
1
) (
ASIGNATURA
) (
CORTE
) (
ESTUDIANTE
) (
PROFESOR
) (
1..*
)
 (
1
)
 (
1..*
) (
1..*
) (
1
) (
1
)
 (
1
) (
1..*
) (
1..*
)
 (
1..*
)
 (
1..*
) (
1
)
 (
1..*
) (
1..*
) (
1..3
)
 (
1..*
)
Referencias
Teorema de Cap, wikipedia. Link: https://es.wikipedia.org/wiki/Teorema_CAP
Graph Database for Beginners, link: https://go.neo4j.com/rs/710-RRC-335/images/Graph_Databases_for_Beginners.pdf
Learning Neo4j- Rik Van Bruggen, link: http://neo4j.com/book-learning-neo4j/
B
ASES DE DATOS 
ORIENTADA A
 
G
RÁFOS
 
(BDOG)
.
 
BASES DE DATOS NO RELACIONAL.
 
Una
 
base de datos orientada a grafos
 
(
BDOG
) representa la información como nodos de 
un
 
grafo
 
y sus relaciones con las aristas del mismo, de manera que se pueda usar
 
teoría de 
grafos
 
para recorrer la
 
base de datos
 
ya que esta puede 
describir atributos de los nodos 
(entidades) y las aristas (re
laciones).
 
Las 
bases de datos orientadas a grafos o BDOG tiene su principal característica en que 
representan la información en vértices y aristas cumpliendo con la disciplina matemática 
de la Teoría de Grafos
.
 
Un grafo estará compuesto por dos elementos: los nodos (vértices) y las relaciones 
(aristas). Un nodo representa una entidad, en el que almacenaremos piezas de datos o 
atributos de tipo clave
-
valor, mientras que las relaciones 
representan cómo se conectan y 
se asocian dos nodos.
 
En algunos fabricantes de motores de BDOG podremos guardar datos y establecer 
etiquetas en las propias relaciones que nos servirá a posterior en las consultas que 
realicemos para poder filtrar o buscar i
nformación.
 
"Con la base de datos de tipo grafo podríamos demostrar el concepto teórico de los Seis 
grados de separación"
 
Las BDOG pertenecen al grupo de las NoSQL y dentro del teorema de CAP las podríamos 
englobar dentro de CA (Consistency, Availability) 
o PA (Partitioning, Availability). Esto 
puede generar algo de controversia, más adelante veremos los motivos de esta doble 
asignación.
 
Las clasificamos como NoSQL por las siguientes características:
 
·
 
No utilizan un modelo relacional
 
·
 
Carece de un esquema fij
o, podemos tener nodos con diferente número de 
atributos.