0qln
ce0875f29b
Zwei Kompressionsdurchgaenge ueber Kapitel 2-7. Entfernt wurden Redundanzen, Meta-Kommentare, Ueberklaerungen und Fuellsaetze; Fakten, Namen, Daten, Entscheidungen samt Begruendung sowie alle Abbildungen und Tabellen bleiben unveraendert. Reine Textseiten: 78 -> 57 (Woerter 19613 -> 12451). Gesamt-PDF: 138 -> 116 Seiten.
60 lines
4.3 KiB
TeX
60 lines
4.3 KiB
TeX
\section{Ablagekonzept im S3-Speicher}
|
|
\label{sec:s3-layout}
|
|
|
|
Das Ablagekonzept muss zwei Aufgaben erfüllen: die Zuordnung von Dokumenten zu Kunden und die Abbildung des fachlichen Dokumententyps. Beides geschieht ausschließlich über die Struktur im Speicher, ohne eine zusätzliche Datenbank.
|
|
|
|
\subsection{Präfixe statt Ordner}
|
|
|
|
S3 kennt technisch keine Ordner. Jedes Objekt wird über einen Schlüssel in einem flachen Namensraum adressiert. Die scheinbare Hierarchie entsteht beim Auflisten: \texttt{ListObjectsV2} liefert mit Präfix und Trennzeichen nur die Objekte unterhalb eines Präfixes sowie die gemeinsamen Teilpräfixe der nächsten Ebene \autocite{aws-listobjectsv2}. Ein Schlüssel wie
|
|
|
|
\begin{quote}
|
|
\texttt{Beispielkunde GmbH/Service-Protokoll/Protokoll-2026-07.pdf}
|
|
\end{quote}
|
|
|
|
erscheint in Filestash als zweistufige Ordnerhierarchie, ist im Speicher aber nur eine Zeichenkette. Ein „Ordner" existiert erst, wenn mindestens ein Objekt mit dem entsprechenden Präfix vorhanden ist; ein leerer Ordner lässt sich nur durch ein Platzhalterobjekt simulieren, dessen Schlüssel auf das Trennzeichen endet.
|
|
|
|
Abbildung~\ref{fig:s3-layout} zeigt die resultierende Struktur.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=0.85\textwidth]{figures/diagrams/s3-layout.pdf}
|
|
\caption{Ablagestruktur im S3-Speicher}
|
|
\label{fig:s3-layout}
|
|
\end{figure}
|
|
|
|
\subsection{Kundenzuordnung über ein Marker-Objekt}
|
|
|
|
Auf der obersten Ebene des Buckets liegt für jeden Kunden ein Ordner. Dessen Platzhalterobjekt trägt ein benutzerdefiniertes Metadatum \texttt{efecte-org-id} zur Zuordnung an eine Organisation und wird im Folgenden als \emph{Marker} bezeichnet.
|
|
|
|
Er sorgt dafür, dass der Kundenordner auch ohne Dokumente existiert, und trägt die Organisationszugehörigkeit an genau einer Stelle.
|
|
|
|
Die Organisations-ID wird als Metadatum statt als Bestandteil des Ordnernamens geführt (siehe Abschnitt~\ref{sec:feature-analysis}). Die Ordner werden von Kundenbetreuern über Filestash gepflegt; ein Name wie \texttt{42} wäre dort schwer handhabbar. Der lesbare Firmenname bleibt daher der Ordnername, die technische Zuordnung wandert in die Metadaten.
|
|
|
|
Genau diese Entscheidung erzeugt das zentrale technische Problem des Projekts (Abschnitt~\ref{sec:lookup-research}): Houston kennt die Organisations-ID, muss daraus den Ordnernamen ermitteln — und S3 bietet keine Suche nach Metadaten.
|
|
|
|
\subsection{Typisierung über Unterordner}
|
|
|
|
Innerhalb des Kundenordners liegt für jeden der sieben Dokumententypen ein Unterordner. Der Typ ergibt sich aus dem Unterordner; direkt im Kundenordner liegende Dokumente gelten als untypisiert.
|
|
|
|
Die Alternative — den Typ als Metadatum an jeder Datei zu hinterlegen — wurde verglichen:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{Pflegeaufwand:} Ein Metadatum müsste bei jedem Upload manuell gesetzt werden; Filestash bietet hierfür keine komfortable Unterstützung. Das Ablegen in einem Ordner ist die natürliche Bedienhandlung.
|
|
\item \textbf{Abfragbarkeit:} Der Typ ist als Präfixbestandteil unmittelbar aus dem Schlüssel ablesbar. Ein Metadatum müsste dagegen für jedes Objekt einzeln abgerufen werden, da \texttt{ListObjectsV2} benutzerdefinierte Metadaten nicht mitliefert — bei $n$ Dokumenten also $n$ zusätzliche Aufrufe.
|
|
\item \textbf{Filterung:} Eine Filterung nach Typ reduziert sich auf eine Präfixabfrage und ist damit serverseitig umsetzbar.
|
|
\end{itemize}
|
|
|
|
Dem stehen zwei Nachteile gegenüber: Ein Dokument kann nur einen Typ haben, und die Ordner müssen existieren — die automatische Anlage wird damit zu einer eigenen Anforderung (FA-13). Beide Einschränkungen wurden bewusst in Kauf genommen.
|
|
|
|
\subsection{Sichtbarkeitsregeln}
|
|
|
|
Für die Darstellung gelten drei Regeln:
|
|
|
|
\begin{enumerate}
|
|
\item \textbf{Ordner werden nicht als Einträge angezeigt.} Die Liste zeigt ausschließlich Dokumente; die Ordnerstruktur wird über Typ-Icons und Filter abgebildet. Der Benutzer sieht eine flache Liste aller seiner Dokumente.
|
|
\item \textbf{Leere Typordner erscheinen nicht.}
|
|
\item \textbf{Ordner ohne gültiges Marker-Metadatum werden ignoriert.} Fehlt die Organisations-ID, bleibt der Ordner unsichtbar. Der Fall wird protokolliert, führt aber nicht zu einem Fehler.
|
|
\end{enumerate}
|
|
|
|
Die dritte Regel ist eine Sicherheitsmaßnahme: Ein fehlendes Metadatum führt zum Ausschluss, nicht zu einer Vermutung.
|