Datenbank strukturieren
Nun, da Ihre Daten in Tabellen konvertiert sind, sind Sie bereit, die Beziehungen zwischen diesen Tabellen zu analysieren. Kardinalität bezeichnet die Menge an Elementen, die zwischen zwei zusammenhängenden Tabellen interagieren. Das Ermitteln der Kardinalität ist hilfreich, um sicherzustellen, dass Sie die Daten so effizient wie möglich in Tabellen aufgeteilt haben.
Jede Entität kann potenziell eine Beziehung zu jeder anderen haben, aber diese Beziehungen gehören für gewöhnlich einem von drei Typen an:
Eins-zu-eins-Beziehungen
Wenn nur eine Instanz von Entität A für jede Instanz von Entität B vorhanden ist, sagt man, dass sie eine Eins-zu-eins-Beziehung (oft 1:1 geschrieben) haben. Sie können diese Art von Beziehung in einem ER-Diagramm mit einer Linie mit einem Strich an beiden Enden darstellen:
Sofern Sie keinen guten Grund haben, dies nicht zu tun, weist eine 1:1-Beziehung meist darauf hin, dass es sinnvoller wäre, wenn Sie die Daten der beiden Tabellen in einer einzigen Tabelle zusammenfassen würden.
Allerdings wollen Sie Tabellen vielleicht unter bestimmten Umständen in einer 1:1-Beziehung erstellen. Wenn Sie ein Feld mit optionalen Daten wie z. B. „Beschreibung“ haben, das für viele Einträge leer ist, können Sie alle Beschreibungen in eine eigene Tabelle verschieben, um so leeren Platz zu beseitigen und die Datenbank-Performance zu verbessern.
Damit die Daten auch korrekt abgeglichen werden, müssen Sie in jeder Tabelle mindestens eine identische Spalte verwenden (wahrscheinlich den Primärschlüssel).
Eins-zu-viele-Beziehungen
Diese Beziehungen treten auf, wenn ein Eintrag in einer Tabelle mit mehreren Einträgen in einer anderen assoziiert ist. Zum Beispiel kann es vorkommen, dass ein Kunde viele Bestellungen aufgibt oder ein Gast mehrere Bücher gleichzeitig aus der Bücherei ausleiht. Eins-zu-viele-Beziehungen (1:m) werden mit einer sogenannten „Krähenfuß-Notation“ angegeben, wie in diesem Beispiel:
Zur Implementierung einer 1:m-Beziehung bei der Einrichtung einer Datenbank müssen Sie einfach nur den Primärschlüssel von der „einen“ Seite der Beziehung als Attribut zu der anderen Tabelle hinzufügen. Wenn ein Primärschlüssel in einer anderen Tabelle auf diese Weise aufgeführt ist, wird er als Fremdschlüssel bezeichnet. Die Tabelle auf der „1“-Seite der Beziehung wird als übergeordnete Tabelle der untergeordneten Tabelle auf der anderen Seite betrachtet.
Viele-zu-viele-Beziehungen
Wenn mehrere Entitäten aus einer Tabelle mit mehreren Entitäten in einer anderen Tabelle assoziiert werden können, ist das eine Viele-zu-viele-Beziehung (n:m). Das kann bei Studenten und Kursen passieren, weil ein Student viele Kurse belegen und ein Kurs viele Studenten aufnehmen kann.
In einem ER-Diagramm werden diese Beziehungen durch folgende Linien gekennzeichnet:
Leider lässt sich diese Art von Beziehung nicht direkt in einer Datenbank implementieren. Stattdessen müssen Sie diese in zwei 1:m-Beziehungen aufspalten.
Dazu müssen Sie eine neue Entität zwischen diesen beiden Tabellen erstellen. Wenn die n:m-Beziehung zwischen Verkäufen und Produkten besteht, können Sie diese Entität zum Beispiel „verkaufte_produkte“ nennen, da sie den Inhalt jedes einzelnen Verkaufs zeigt. Sowohl die Verkäufe- als auch die Produkt-Tabelle hätten dann eine 1:m-Beziehung zu „verkaufte_produkte“. Diese Art der Zwischenentität wird in verschiedenen Modellen als Verknüpfungstabelle, assoziative Entität oder Verbindungstabelle bezeichnet.
Jeder Eintrag in der Verknüpfungstabelle fügt zwei Entitäten in den angrenzenden Tabellen zusammen (und kann auch ergänzende Informationen enthalten). Eine Verknüpfungstabelle zwischen Studenten und Kursen kann zum Beispiel so aussehen:
Pflicht oder Kür?
Eine andere Methode zur Analyse von Beziehungen ist die Überlegung, welche Seite der Beziehung existieren muss, bevor die andere existieren kann. Die optionale Seite kann mit einem Kreis auf der Linie markiert werden, wo sonst ein Freiraum zwischen den Strichen wäre. Es muss zum Beispiel ein Staat existieren, damit dieser einen UN-Vertreter hat. Das Gegenteil ist jedoch nicht der Fall:
Zwei Entitäten können voneinander abhängen (eine kann nicht ohne die andere existieren).
Rekursive Beziehungen
Manchmal verweist eine Tabelle auf sich selbst. Eine Tabelle mit Mitarbeitern kann zum Beispiel das Attribut „Manager“ haben, das auf eine andere Person in derselben Tabelle verweist. Das wird als rekursive Beziehung bezeichnet.
Redundante Beziehungen
Eine redundante Beziehung ist eine Beziehung, die mehr als einmal ausgedrückt wird. Üblicherweise könnten Sie eine der Beziehungen entfernen, ohne wichtige Informationen zu verlieren. Wenn zum Beispiel eine Entität namens „Studenten“ eine direkte Beziehung zu einer anderen Entität namens „Dozenten“ hat, aber auch indirekt eine Beziehung zu den Dozenten durch „Kurse“, sollten Sie die Beziehung zwischen „Studenten“ und „Dozenten“ entfernen. Es ist besser, diese Beziehung zu löschen, weil die Studenten den Dozenten nur über Kurse zugewiesen werden.
Warten der Datenbank
Berechnen Sie den erforderlichen Datenbankspeicherplatz
Vor der Reduzierung des Speicherplatzes sollten Sie feststellen, wie viel Speicherplatz Sie insgesamt benötigen. Der Datenbankspeicher basiert auf den folgenden Faktoren: Protokollgröße und Ablaufzeitraum.
Die Anzahl der Clientcomputer.
Die durchschnittliche Anzahl der Viren pro Monat.
Die Anzahl der Ereignisse, die in jedem Protokoll verbleiben müssen.
Für jedes Content-Update sind über 300 MB erforderlich. Herunterladen von Inhalt aus LiveUpdate auf Symantec Endpoint Protection Manager Wiederherstellen einer älteren Version der Symantec Endpoint Protection Die Anzahl an Content-Updates.
Wenn Sie beispielsweise sowohl 32-Bit- als auch 64-Bit-Clients haben, benötigen Sie die doppelte Anzahl von Sprachversionen. Die Anzahl der Clientversionen, die Sie für jede Sprache beibehalten müssen.
Die Backup-Größe entspricht etwa 75 Prozent der Datenbankgröße, multipliziert mit der Anzahl der gespeicherten Backup-Kopien, die Sie behalten haben. Die Anzahl der Backups, die Sie behalten müssen. Weitere Informationen darüber, wie der von Ihnen benötigte Festplattenspeicher berechnet wird, finden Sie im Symantec-Whitepaper, Symantec Endpoint Protection-White Paper mit Empfehlungen zur Größenbestimmung und Skalierbarkeit
Was ist für ein Datenbank-Backup geplant
Was geschieht mit den geplanten Backups, wenn der SnapManager Server neu gestartet wird? Beim Neustart des SnapManager-Servers werden alle Zeitpläne automatisch neu gestartet. SnapManager wird jedoch nicht zu verpassten Vorkommnissen nachgehen.
Was geschieht, wenn zwei Backups gleichzeitig auf zwei Datenbanken geplant werden? SnapManager startet die Backup-Vorgänge nacheinander und ermöglicht es dann, die Backups parallel auszuführen. Wenn ein Datenbankadministrator beispielsweise sechs tägliche Backup-Pläne für sechs verschiedene Datenbankprofile erstellt, die um 1:00 Uhr stattfinden, werden alle sechs Backups parallel ausgeführt. Wenn für einen kurzen Zeitraum mehrere Backups auf einem einzelnen Datenbankprofil geplant werden, führt der SnapManager-Server nur den Backup-Vorgang mit der längsten Aufbewahrungsdauer aus. Vor dem Starten eines Backup-Vorgangs legt SnapManager zunächst Folgendes fest: Hat ein anderer Zeitplan in den letzten 30 Minuten erfolgreich ein Backup mit größerer Aufbewahrung für dasselbe Profil erstellt?
Wird ein anderer Zeitplan innerhalb der nächsten 30 Minuten versuchen, ein Backup mit größerer Aufbewahrung für dasselbe Profil zu erstellen? Wenn die Antwort auf eine der Fragen „Ja“ lautet, wird das Backup von SnapManager übersprungen. Beispielsweise kann ein Datenbankadministrator einen täglichen, wöchentlichen und monatlichen Zeitplan für ein Datenbankprofil erstellen, der alle Backups um 1:00 Uhr vorbestimmt sind An diesem Tag des Monats, an dem drei Backups gleichzeitig um 1:00 Uhr stattfinden sollen, führt SnapManager nur den Backup-Vorgang aus, der auf dem monatlichen Zeitplan basiert. Das Zeitfenster von 30 Minuten kann in einer SnapManager-Eigenschaftendatei geändert werden.
Unter welchem Benutzer wird die Sicherung ausgeführt? Der Vorgang wird unter dem Benutzer ausgeführt, der den Zeitplan erstellt hat. Sie können dies jedoch in Ihre eigene Benutzer-ID ändern, wenn Sie sowohl für das Datenbankprofil als auch für den Host gültige Anmeldeinformationen haben. Durch das Starten von geplanten Backup-Eigenschaften für den von Avida Davis erstellten Backup-Zeitplan kann Stella Morrow beispielsweise seine Benutzer-ID für diesen Vorgang als Benutzer auswählen, um das geplante Backup auszuführen.
Wie funktioniert der SnapManager Scheduler mit dem systemeigenen Scheduler? Auf dem SnapManager-Server können Sie die geplanten Backups nicht über den systemeigenen Scheduler des Betriebssystems anzeigen. Zum Beispiel, nach dem Erstellen eines geplanten Backups, sehen Sie keine zusätzlichen Einträge in cron.
Was passiert, wenn die Uhren in der grafischen Benutzeroberfläche und der Server nicht synchronisiert sind? Die Uhren auf Client und Server werden nicht synchronisiert. So können Sie ein Backup planen, bei dem sich die Startzeit künftig auf dem Client, aber in der Vergangenheit auf dem Server befindet. Bei wiederkehrenden Backups erfüllt der Server die Anforderung immer noch. Wenn der Server beispielsweise eine Anfrage erhält, stündliche Backups ab dem 01/30/08 um 3:00 Uhr durchzuführen Aber die aktuelle Zeit ist 3:30 Uhr An diesem Tag führt der Server sein erstes Backup um 4:00 Uhr durch Und führt weiterhin Backups jede Stunde durch. Für einmalige Backups übernimmt der Server jedoch die Anfrage wie folgt: Wenn sich die Startzeit innerhalb der letzten fünf Minuten nach der aktuellen Serverzeit befindet, beginnt SnapManager sofort mit dem Backup.
Wenn die Startzeit größer als fünf Minuten ist, startet SnapManager das Backup nicht. Betrachten wir zum Beispiel das folgende Szenario: Die Uhr im Host der grafischen Schnittstelle liegt drei Minuten hinter der eigentlichen Zeit.
Die aktuelle Zeit auf dem Client ist 8:58 Uhr
Sie planen, ein einmalig auszusichertes Backup um 9:00 Uhr zu erstellen
Sie planen ein weiteres, einmalig zu besichertes Backup um 8:30 Uhr Wenn der Server die erste Anforderung erhält, ist die Uhrzeit auf dem Server 9:01 Uhr Obwohl sich die Startzeit für das Backup in der Vergangenheit befindet, führt SnapManager sofort das Backup durch. Wenn der Server die zweite Anforderung erhält, beträgt der Startzeit des Backups mehr als fünf Minuten in der Vergangenheit. Sie erhalten eine Meldung, dass die Terminanfrage fehlgeschlagen ist, da die Startzeit in der Vergangenheit liegt. Sie können die Zeit von fünf Minuten in einer SnapManager-Eigenschaftendatei ändern.
Was geschieht mit den geplanten Backups für ein Profil, wenn das Profil gelöscht wird? Wenn ein Datenbankprofil gelöscht wird, löscht der SnapManager-Server geplante Backups, die für dieses Profil definiert wurden.