Benötige Hilfe - Datenbankaufbau

[Fabi]

Hallo Leute,

ich habe einen Datenbankaufbau für die Speicherung von Protokollierungsdaten von Checkpoint-Firewalls entworfen. Nur leider bin ich jetzt mit meinem Latein am Ende. Die Datenbank enthält sicherlich noch einige Redundanzen, nur habe ich keine Ahnung mehr, wie ich sie noch aufteilen könnte, damit es programmiertechnisch noch akzeptabel wäre.

Hier ist der Link zu dem Word-Dokument mit dem ER-Modell, einer Beschreibung des allgemeinen DB-Aufbaus und einer Beschreibung der Attribute. Ich wäre sehr erleichtert, wenn ihr mir ein paar Tipps geben könntet.

Datenbankaufbau Checkpoint

Vielen Dank im Voraus.

Viele Grüße,

Fabian Weber

[Goos]

Deine Beschreibung zu den einzelnen Tabellen ist aber nicht ganz vollstaendig

Aber mal eine Frage von mir. Weshalb beabsichtigst du fuer 4 verschiedene Events auch gleich 4 verschiedene Tabellen anzulegen, wo diese 4 Tabellen doch offensichtlich zu ueber 90 % gleich sind?

Goos

[Fabi]

Ich bekam den Datenbankaufbau so vorgelegt. Ich denke mal, weils programmiertechnisch leichter ist.

Ich hätte mir gedacht, die ersten 4 Attribute aller Tabellen(action,...) in cpEvents zu verschieben und die ersten 18 Attribute aus cpTraffic, ... noch in eine extra Tabelle auszulagern, aber dann wird’s ja programmiertechnisch schlechter.

Wenn ich zum Beispiel eine Auswertung über alle attacks von Zeit1 bis Zeit2 haben möchte, muss ich :

Select logNr, action, origIpNr, ifdir, ifname from cpEvents where eventDateTime between zeit1 and zeit2;

Dann eine Schleife über das Resultset

in der Schleife select * from zwischentabelle(cpAttack) where (PRIMÄRSCHLÜSSEL) = LogNr

ebenfalls in der Schleife: select * from cpAttack where (PRIMÄRSCHLÜSSEL) = LogNr

Ich weis jetzt halt auch nich mehr weiter. Ich weiß nur noch, dass es sich hierbei dann um ISA-Beziehungen handelt. Aber wie man die in der DB darstellt. Keine Ahnnung

[Goos]

Wenn ich zum Beispiel eine Auswertung über alle attacks von Zeit1 bis Zeit2 haben möchte, muss ich :

Select logNr, action, origIpNr, ifdir, ifname from cpEvents where eventDateTime between zeit1 and zeit2;

Dann eine Schleife über das Resultset

in der Schleife select * from zwischentabelle(cpAttack) where (PRIMÄRSCHLÜSSEL) = LogNr

ebenfalls in der Schleife: select * from cpAttack where (PRIMÄRSCHLÜSSEL) = LogNr

Hmmm wie kommst auf sowas und was hast du da genau vor? Was ist zum Beispiel deine Zwischentabelle?

Ach und Schleifen, bzw Cursor ueber Resultsets solltest eh vermeiden, wo du nur kannst. (Gerade in diesem Fall, wo du sie nichtmal brauchst)

Goos

[Fabi]

Ich möchte einen relationalen, normalisierten Datenbankaufbau von dem, was da jetzt vorhanden ist.

Hintergrund ist folgender. Die Datensätze kommen über Syslog rein. Mein Abschlussprojektarbeit zum FIAE besteht daraus, einen Parser für diese Datensätze zu schreiben. Der das dann natürlich in eine Datenbank schreibt.

Später soll dann ein Webfrontend für das geschrieben werden. Also alle möglichen Auswertungen. Zum Beispiel alle Rejects an einem Tag......

[Fabi]

Hier ist der aktualisierte Datenbankaufbau. Was hält ihr davon.

Datenbankaufbau 2

[carstenj]

Hi,

find ich extremst zu kompliziert. Ich würde schon alle gleichen Daten zusammenfassen, z. B. in einer Tabelle Header oder so. Man kann sich auch "vernormalisieren".

Kurzum: Eine Mischung aus dem ersten und zweiten Modell. Ein ER Diagramm ist sicher ganz hilfreich, je komplizierter du die Datenbank designst, desto schwieriger wird es, daraus sinnvolle Daten auszulesen.

[Goos]

Hier ist der aktualisierte Datenbankaufbau. Was hält ihr davon.

Falls dich meine Meinung interessiert.

Ich halts fuer ne totale Katastrophe

Ein gutes Beispiel, wie mans nicht machen sollte.

Du hast da einfach jede Menge absolut ueberfluessige Tabellen angelegt.

Goos

[Jasper]

Hier ist der aktualisierte Datenbankaufbau. Was hält ihr davon.

ist übernormalisiert. bestes beispiel sind die ip-adressen in der tabelle cptraffic.

tabellen in kleine schnipsel zu zerlegen hat nichts mit normalisierung zu tun.

-j

[Fabi]

Wenn ihr das zu kompliziert findet, dann habt ihr euch sicher noch nie das ER-Modell von SAP R/3 oder IFS-Applications angesehen. Die bestehen fast ausschließlich aus Fremdschlüsseln. Im Vergleich zu diesen ist mein ER-Modell unternormalisiert.

[tuxfriend]

Wenn ihr das zu kompliziert findet, dann habt ihr euch sicher noch nie das ER-Modell von SAP R/3 oder IFS-Applications angesehen. Die bestehen fast ausschließlich aus Fremdschlüsseln. Im Vergleich zu diesen ist mein ER-Modell unternormalisiert.

<ironie>Deswegen funktioniert SAP ja auch so hervorragned </ironie>

Normalerweise normalisiert man bis zur 3. Normalform. Alles was danach kommt ist mit bisher in der Praxis noch nicht begegnet, zugegebenermaßen gehören Mamutsysteme wie SAP bei mir nicht dazu. Ich kenne aber z.B. das Datenmodell von Apertum und anderen mittleren WaWis, das ist bei weitem nicht so normalisiert, so wie ich das sehe nur bis zu besagter 3. NF. Die vierte würde ich mir denn bei solchen Systemen schon noch wünschen aber dann ist auch Schluß.

Ich denke eigentlich, dir würde auch die 3. NF reichen.

Man muß sich immer auch überlegen, das Queries mit vielen joins auch leicht mal etwas langsam werden. Da ist es gelegentlich angeraten etwas weniger zu Normalisieren. Und eine Tabelle die außer dem Primärschlüssel nur ein einziges Attribut hat ist eigentlich nur dann nötig, wenn man schon eine Erweiterung des Datenmodells im Kopf hat, in der diese Tabelle mehrere Attribute bekommen würde.

Gruß Nils

[Jasper]

Wenn ihr das zu kompliziert findet, dann habt ihr euch sicher noch nie das ER-Modell von SAP R/3 oder IFS-Applications angesehen. Die bestehen fast ausschließlich aus Fremdschlüsseln. Im Vergleich zu diesen ist mein ER-Modell unternormalisiert.

dann erklär mir bitte, welche NF der ausgliederung der ip-adressen aus der traffic-tabelle zugrunde liegt. ich lerne gern dazu.

-j

[carstenj]

Hi,

nach der Normalisierung, wie sie in manchen Büchern steht, ist eine Datenbank quasi im "Idealzustand". Irgendwann ist das in der Realität aber vielleicht nicht mehr handelbar, oder es ist einfach unpraktisch. Dein System mag auch funktionieren, aber toll ist es nicht.

Und wenn für dich gut = kompliziert ist, dann lass es so.

[Goos]

Wenn ihr das zu kompliziert findet, dann habt ihr euch sicher noch nie das ER-Modell von SAP R/3 oder IFS-Applications angesehen. Die bestehen fast ausschließlich aus Fremdschlüsseln. Im Vergleich zu diesen ist mein ER-Modell unternormalisiert.

*lach*...also ich glaub du vergleichst da Silvesterkracher mit ner Atombombe

Dein Modell ist uebrigens nicht unternormalisiert, sondern unnoetig fragmentiert.

Kannst du mir erklaeren, weshalb du in so vielen Faellen einfach irgendwelche Attribute durch vorher nicht vorhandene Zahlen ersetzt und die Attribute dann in eine neue Tabelle auslagerst?

Es mag ja in einigen wenigen Faellen auch Gruende dafuer geben, aber du machst das mit quasi allen Attributen.

Verrate mir doch bitte mal, wieso du das machst und was das deiner Ansicht nach mit Normalisierung zutun hat.

Goos

[Fabi]

Das mit dem Auslagern hat den Grund, dass die Datenbank möglichst redundanzfrei ist. Es werden später schätzungsweise ca 1 mio Datensätze gespeichert werden. Und jetzt zum Beispiel zu den IP-Adressen. Es braucht sicherlich weniger Speicher bei einer IP-Adresse die 100000 mal gleich ist, eine Zahl in ein Feld zu schreiben, anstatt immer wieder den String.(Jaja, ich weis, dass Datenbanksystem das eh komprimieren, aber trotzdem ist das dann nicht redundanzfrei)

@Goos: Warum, ist der Vergleich so abwegig. Man lernt ja, in dem man sich von jemandem, der es besser weis, es sich erklären lässt. Und SAP ist wohl ein gutes Vorbild.

[Jasper]

dann schreibst du vermutlich in einer adressdatenbank die hausnummer und die strasse auch in extra tabellen und velinkst diese dann. welche normalformen diesem design zugrunde liegen sollen weiss ich zwar immer noch nicht, aber ich wünsche dir noch viel spass mit deinem design.

-j

[carstenj]

Hi,

Das mit dem Auslagern hat den Grund, dass die Datenbank möglichst redundanzfrei ist.

Ja, das ist auch ein Ziel der Normalisierung.

@Goos: Warum, ist der Vergleich so abwegig. Man lernt ja, in dem man sich von jemandem, der es besser weis, es sich erklären lässt. Und SAP ist wohl ein gutes Vorbild.

äh...es mag erfolgreich sein. Das kann man gerne nachmachen. Aber alle Leute die ich kenne und die damit arbeiten, halten SAP schon für unnötig komplex. Und ob man eine Anwendung schreibt, die man selbst benutzt oder eine die von Millionen Menschen benutzt wird ist auch noch ein Unterschied. Und SAP ist ja auch gewachsen, da werden Sachen irgendwann mal komplizierter als sie sein müssen. Deswegen würde ich, wenn ich bei 0 anfange, das eben schon sehr ordentlich und übersichtlich machen, damit ich da später auch noch durchblicke. Das ist bei deinem Modell nicht der Fall.

Du solltest einfach mehrere Beispiele als Grundlage nehmen, statt verbohrt auf SAP zu pochen. 1 Mio Datensätze sich nicht so viel, wie du denkst. Es gibt mit Sicherheit den ein oder anderen hier der ähnliche Dinge schon gemacht hat, deswegen solltest du dir überlegen, ob du SAP zugrunde legst oder auf die Tipps hier hörst.

[Fabi]

Ich werds nochmal überdenken. Aber eine andere Frage. Wie ist das eigentlich mit der Performance bei MySQL. Bei schätzungsweise 1 - 10 mio Datnsätzen. Kann das MySQL überhaut noch anständig verarbeiten? Hat jemand hier Erfahrung?

[carstenj]

Hi,

ja, überhaupt kein Problem. Dieses Forum hier läuft doch auch auf MySQL, und sehr viele weitere Foren ebenfalls. Da kommt schon allerhand zusammen, und es ist performant genug.

Als Beispiel nimm das hier:

http://forums.gentoo.org/

Natürlich hängen da auch entsprechend starke Rechner hinter, aber MySQL wird wohl kein Flaschenhals werden.

[Goos]

@Goos: Warum, ist der Vergleich so abwegig. Man lernt ja, in dem man sich von jemandem, der es besser weis, es sich erklären lässt. Und SAP ist wohl ein gutes Vorbild.

Ja Fabi, genau so ist das

Man laesst es sich erklaeren und schreibt nicht einfach blind von irgendwelchen Leuten ab, von denen man denkt, dass sie es besser wissen.

Wenn du es dir von den SAP-Datenbank-Leuten hast erklaeren lassen, dann hast sicher ne Menge gelernt, ansonsten hast nur versucht etwas deiner Meinung nach "Gutes" nachzuahmen ohne dabei auf die Randbedingungen zu achten.

Goos

[Goos]

Ich werds nochmal überdenken. Aber eine andere Frage. Wie ist das eigentlich mit der Performance bei MySQL. Bei schätzungsweise 1 - 10 mio Datnsätzen. Kann das MySQL überhaut noch anständig verarbeiten? Hat jemand hier Erfahrung?

Bei deinem momentanen DB-Design koennte das bei ein paar Mio. Datensaetzen eventuell schon zu Problemen kommen

Du musst halt immer beide Seiten im Auge behalten.

Design(Speicherplatzbedarf) <=> Performance

Grundsaetzlich ist MySQL aber problemlos faehig soviele Datensaetze zu vearbeiten.

Goos