In diesem Punkt:

Bestimmung von Datenbanktypen & Fokusdatenbanken

Die Appliance kategorisiert eine gefundene NSF/NTF-Instanz automatisch in eine der folgenden Kategorien:

1. Benutzer-Mail-Datenbank (identifiziert durch ein Personendokument, das auf die Instanz verweist)
2. Mail-In-Datenbank (identifiziert durch ein Nicht-System-Mail-In-Dokument …)
3. Systemdatenbank (identifiziert über bekannten Datei- oder Vorlagennamen)
4. mail.box-Datenbank (aus den Konfigurationseinstellungen des Domino-Servers identifiziert)
5. Verzeichnis (identifiziert aus Domino-Serverkonfiguration/verwendeter Vorlage)
6. Verwaiste Benutzer-Mail (Benutzer-Mail-Dateien, die keinem Personendokument mehr zugeordnet sind)
7. Anwendungsdatenbanken (alle verbleibenden nicht in Kategorie 1-6) kategorisiert

Wenn eine NSF/NTF-Instanz einmal auf einem Server kategorisiert wird, werden alle vorhandenen Instanzen mit derselben Replikat-ID derselben Kategorie zugeordnet. Diese Angabe ändert sich nach dem erstmaligen Scannen einer Instanz nicht, es sei denn, es ändert sich etwas in der Infrastruktur, es werden Server hinzugefügt, das Design oder die ACL geändert oder der Berechnungsalgorithmus optimiert (z. B. mit einem neuen release of iDNA Applications).

Anhand der identifizierten Typen werden die DBs in zwei Gruppen eingeteilt: „Fokusdatenbanken" (bestehend aus Anwendungen und Mail-in Dbs) und „Andere Datenbanken" (bestehend aus den restlichen Datenbanktypen).

Der Großteil der detaillierten Nutzungs- und Designanalysen wird auf Focus DBs durchgeführt, es gibt jedoch eine Vielzahl von Diagrammen und Berichten mit Informationen zu den anderen Typen.

Zusätzliche Informationen außerhalb des Geltungsbereichs von iDNA Applications zu diesen anderen DB-Typen und Infrastrukturthemen finden Sie in panagenda iDNA. Bitte Überprüfen Sie unsere Website oder kontaktieren Sie uns für weitere Informationen.

Nutzerzugriffstage im Vergleich zu Sitzungen

Jedes Mal, wenn ein Benutzer auf eine Anwendung zugreift, wird eine Sitzung eingerichtet. Tagsüber können Benutzer mehrere Sitzungen haben, wenn Sitzungen geschlossen werden, sich Benutzer abmelden/neu anmelden oder weil sie mehrere Fenster oder Clients verwenden. So kann ein Benutzer, der über den Tag auf eine Anwendung zugreift, zu mehreren Sitzungen führen. Sitzungen können auch auftreten, wenn Server und Prozesse auf Datenbankinstanzen zugreifen.

Ein Benutzerzugriffstag wird als ein eindeutiger Benutzer identifiziert, der an einem bestimmten Tag innerhalb des analysierten Zeitraums auf eine Anwendung zugreift.

Es könnte also 20 Sitzungen für Benutzer A geben, der in einem Zeitraum von 7 Tagen auf Anwendung Z zugreift, aber wenn dieser Benutzer nur an Tag 1 und 5 dieses Zeitraums auf die Anwendung zugreift, mit 14 Sitzungen am ersten Tag und 6 am fünften Tag Die Anzahl der Benutzerzugriffstage beträgt weiterhin nur 2. Und wenn beispielsweise 100 einzelne Benutzer an einem Tag auf 100 verschiedene Anwendungen zugreifen, beträgt die Anzahl der „Benutzerzugriffstage“ für diesen Tag 10,000.

In mehreren Diagrammen (z. B. dem Dashboard Nutzung → Nach Abteilung/Standort → Die 25 wichtigsten aktiven Abteilungen/Standorte) wird diese Unterscheidung verwendet, um das Risiko verzerrter Zahlen zu eliminieren und Ihnen eine ausgewogenere Entscheidung zu ermöglichen, wenn es um die Nutzung geht Zahlen.

Designkomplexität, Designkomplexitätsbewertung, Designähnlichkeiten und Design Insights

Design basiert auf der Größe der Designelemente und der Menge an Quellcode in diesen Elementen. Die Berechnung wird durch verschiedene Überlegungen wie Codesprachentyp, Verwendung von Leser-/Autorfeldern, benutzerdefinierte XPages-Steuerung usw. verfeinert.

Designähnlichkeit Die Analyse gibt an, wie ähnlich eine Datenbank allen anderen analysierten Datenbanken ist. Datenbanken mit hoher Ähnlichkeit werden in Design-Cluster gruppiert, was eine schnelle Identifizierung von Replikaten ermöglicht, die von einem gemeinsamen Design abweichen können. Es bietet auch Mittel zum Identifizieren von "Vorlagenkandidaten" für Datenbanken, für die keine Vorlage angegeben ist.

Design Insights sind Kombinationen bestimmter Muster, die im Quellcode vorkommen. Diese Kombinationen werden als "Ergebnisse" bezeichnet und können alles sein, von der Identifizierung von Plattformabhängigkeiten, wenn auf lokale DLLs verwiesen wird, bis hin zum Verständnis, ob ein Codeabschnitt mit anderen Datenbanken interagiert.

Bewertung der Designkomplexität ist eine Kategorisierung von sieben Stufen von "Unwesentlich" bis "Außergewöhnlich", die die Auswirkungen einer Neugestaltung oder Migration der Anwendung angeben. Der Design Impact wird aus drei Hauptquellen berechnet: Komplexität, Insights und Ähnlichkeit.

Nächstes Thema:

Datenerfassung und Zeitbeschränkungen (Server, die abgefragt werden_ Erfassungszeitraum)