Principios de diseño de base de datos de gráficos, principios generales y problema de granularidad

Question

En el diseño de bases de datos relacionales, existen formas normales para guiar el proceso de diseño. ¿Existen principios similares que se aplican al diseño de bases de datos de gráficos como neo4j?

En particular, estoy desconcertado por la granularidad del problema: podría diseñar una base de datos de gráficos donde la mayoría de los atributos están almacenados en los vértices (un contacto tiene nombre de atributos, fecha de nacimiento, ...) o podría almacenar la mayoría de los datos en las relaciones (conectando el contacto con una relación de "primer nombre" con otro vértice que contiene la información real) o podría hacer ambas cosas (luego, por supuesto, surgen problemas de consistencia, pero puede acelerar los tiempos de recuperación).

Estos problemas son similares a mis preguntas para principiantes cuando comencé a diseñar SQL y muchos de los problemas solo se podían resolver ganando experiencia. ¿Todavía puede recomendar un buen libro práctico sobre los conceptos básicos de este tema o indicarme dónde encontrar algunos principios generales?

Answer 1

No hay nada que haya visto que se tome como una verdad como la normalización en las bases de datos relacionales. Sin embargo, recomendaría dos cosas:

1) Modele sus entidades (nodos) como lo haría normalmente. Los atributos de esas entidades son cosas que pertenecen específicamente a esas entidades y existen fuera de las relaciones (conexiones).

2) Modele sus relaciones (bordes) como lo haría normalmente. Esos atributos no deberían existir, excepto cuando dos entidades (nodos) están relacionadas (conectadas).