Describe a simple tree diagram
This commit is contained in:
parent
450f0cee18
commit
0c9a3fc59d
|
@ -1,11 +1,77 @@
|
|||
\chapter{Arborescences et graphs}
|
||||
|
||||
Les arborescences et les graphs sont deux structures de données extrêmement utiles et souvent rencontrées dans les applications modernes.
|
||||
Le cas le plus simple pourrait être un forum de discussions \footnote{Anciennement, PhpBB permettait de répondre à un message antérieur, et copiait pour cela le message en question dans le nouveau encart. Niveau traçabilité, on était plus proche du zéro absolu que de la blockchain.}, un réseau social ou une plateforme de discussions chiffrée \footnote{iMessages est sans doute plus évolué que Signal à ce sujet, mais les deux permettent bien de répondre à un message en particulier}, où un intervenant `A` a la possibilité de répondre à un message antérieurement publié.
|
||||
|
||||
\section{Arborescences}
|
||||
|
||||
Il est possible de voir une arborescence comme un graph dirigé dont chaque noeud n'aurait au maximum qu'une seule relation vers son parent.
|
||||
Chaque niveau de l'arborescence est un \texttt{noeud}, tandis que les noeuds n'ayant aucun enfant sont des \texttt{feuilles}.
|
||||
|
||||
\begin{graphic}{images/trees/tree01.png}
|
||||
\caption{Un exemple d'arborescence sur quatre niveaux}
|
||||
\end{graphic}
|
||||
|
||||
\subsection{Tables liées}
|
||||
|
||||
La représentation d'une arborescence grâce à des tables est la plus simple que nous pourrons trouver: elle consiste à créer une table par niveau devant être représenté.
|
||||
|
||||
\begin{minted}{python}
|
||||
|
||||
from django.db import models
|
||||
|
||||
|
||||
class Level1(models.Model):
|
||||
name = models.CharField(max_length=255)
|
||||
|
||||
|
||||
class Level2(models.Model):
|
||||
name = models.CharField(max_length=255)
|
||||
parent = models.ForeignKey(Level1, null=True, blank=True)
|
||||
|
||||
|
||||
class Level3(models.Model):
|
||||
name = models.CharField(max_length=255)
|
||||
parent = models.ForeignKey(Level2, null=True, blank=True)
|
||||
|
||||
|
||||
class Level4(models.Model):
|
||||
name = models.CharField(max_length=255)
|
||||
parent = models.ForeignKey(Level3, null=True, blank=True)
|
||||
|
||||
\end{minted}
|
||||
|
||||
Cette représentation est réellement simpliste, et même si elle peut répondre rapidement à un besoin, nous nous rendons compte rapidement des limites de ce système:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Il est impossible de \textbf{déplacer} une instance d'un niveau vers un autre: tant que l'on restera au même niveau, il sera possible de modifier le parent, mais pas de changer un objet de niveau.
|
||||
\item Si nous souhaitons ajouter un nouveau niveau, cela reviendra à ajouter une nouvelle classe (et donc, une nouvelle table).
|
||||
\item La récupération de données (ie. \textit{Le chemin complet vers une entité}) reviendra à exécuter autant de requêtes qu'il y a de niveaux avant la racine.
|
||||
\end{enumerate}
|
||||
|
||||
Ces points impliquent que l'évolutivité de la solution sera rapidement compromise.
|
||||
|
||||
\subsection{Listes adjacentes}
|
||||
|
||||
|
||||
|
||||
\subsection{\textit{Jaywalking}}
|
||||
|
||||
|
||||
|
||||
\subsection{\textit{Modified Preorder Tree Traversal}}
|
||||
|
||||
|
||||
|
||||
\subsection{Closure tables}
|
||||
|
||||
On a un exemple de remplissage/vidage d'une closure table, mais il faudrait en fait présenter les listes adjacentes et les autres structures de données.
|
||||
Comme ça on pourra introduire les graphs juste après.
|
||||
|
||||
\begin{minted}{python}
|
||||
\begin{minted}[tabsize=4]{python}
|
||||
# <app>/management/commands/rebuild.py
|
||||
"""This command manages Closure Tables implementation
|
||||
|
||||
It adds new levels and cleans links between entities.
|
||||
This way, it's relatively easy to fetch an entire tree with just one tiny
|
||||
request.
|
||||
|
@ -34,3 +100,7 @@ class Command(BaseCommand):
|
|||
for tree_path in tree:
|
||||
tree_path.delete()
|
||||
\end{minted}
|
||||
|
||||
\section{Graphs}
|
||||
|
||||
La représentation de graphs est hors de ce périmètre: il conviendrait d'aborder des bases de données ayant un modèle différent d'un modèle relatonnel, sans quoi les performances seront atrocement complexes et abominables \cite[p. 49-55]{data_intensive}.
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 14 KiB |
Loading…
Reference in New Issue