Eigenschaften von Redundanz - ein Brainstorming

[JanHoener]

Hallo zusammen.
Mir fällt es in der Tat schwer, einige Eigenschaften von Redundanz im GROUPWARE zu finden. Ich würde mich freuen, wenn ihr hier etwas Brainstorming betreibt und mir etwas helft.
Ich habe bisher folgendes:

1) verteilt: gleiche Dokumente/Datenbanken liegen verteilt auf Laptops der User
2) mehrfach: zur Ausfallsicherheit existieren neben den "normalen" Datenbanken oft eine Backup-DB, auf die zur Not zurückgegriffen werden kann
3) doppelt: in einer View existieren mehrere Dokumente für das gleiche Objekt
4)...

vielen Dank für eure Hilfe.

Gruß Jan

[Don Pasquale]

Hallo Jan,

hörst sich ja an wie eine Hausaufgabe ;-) Ok, leider begreife ich nicht
was Du genau benötigst. Kannst Du Deine Frage nochmal stellen ?
Du hast folgendes m.E. unklar formuliert :
 - Eigenschaften von Redundanz : Redundanz IST doch eine Eigenschaft
 - Redundanz im GROUPWARE: Was ist GROUPWARE ? Ein Produkt ?
Oder meinst Groupware im allgemeinen, also Tools für verteiltes Arbeiten ?
Könntest Du folgendes meinen:
Vorkommen von Redundanz in Groupware, i.E. Louts Notes ?
Und kannst Du vielleicht noch das Ziel umreissen ? Beweis für dies, im Gegensatz zu Outlook.

Auf ein neues

Ciao
Don Pasquale

[JanHoener]

hallo.
ist keine hausaufgabe sondern gegenstand einer seminararbeit. :-)
redundanz ist zwar eine eigenschaft, aber sie kann ja in verschiedenster art und weise auftauchen. blau ist auch eine eigenschaft, aber es gibt ja auch preußenblau, marineblau usw. :-)

ich meine mit Groupware ein Tool für verteiltes Arbeiten.
Und du hast recht: ich suche das Vorkommen von Redundanz in Groupware, i.E. Lotus Notes.
Ziel ist es, den Begriff Redundanz zu umreissen.
Ich habe das zwar schon gemacht, aber nicht zur Zufriedenheit meines Betreuers. Ich habe zu wenig Struktur drin. Mein neuer Leitfaden:
1) Einleitung
2) Redundanzdefinition
3) Eigenschaften von Redundanz
4) Gründe und Ursachen von Redundanz
5) Folgen von Redundanz

gruß jan

[Don Pasquale]

@Ja,

viele Stoff sehe ich da nicht, Du hast ja fast schon alles aufgezählt.

1) verteilt: gleiche Dokumente/Datenbanken liegen verteilt auf Laptops der User

Das ist doppelt gemoppelt:
Die Datenbanken können sowohl auf dem Server als auch auf den Laptops der User liegen, eine exakte Kopie ist es meist nur zum Zeitpunkt der Replikation bzw. des Abgleichs. Logischerweise sind dann auch alle Dokumente doppelt.

2) mehrfach: zur Ausfallsicherheit existieren neben den "normalen" Datenbanken oft eine Backup-DB, auf die zur Not zurückgegriffen werden kann

OK, ein Backup ist immer Redundant.

3) doppelt: in einer View existieren mehrere Dokumente für das gleiche Objekt

Hier ist ein Denkfehler:
Du hast verschiedene Views
- Liste aller User mit einem Porsche
- Liste aller user mit gelben Autos
- Liste aller user mit Sportwagen

Du ein und dasselbe Objekt. Dieses Eine Objekt kann ich verschiedenen Sichten erscheinen. Es existiert aber nur einmal !
Also KEINE Redundanz.

Ciao
Don Pasquale

Gefahren von Redundanz ?
- 2 Mitarbeiter bearbeiten gleichzeitig denselbe Kunden
Arbeit wurde doppelt gemacht
- 2 Mitarbeiter bearbeiten gleichzeitig denselbe Kunden
schreiben bemerkungen dazu
dasselbe Objekt existiert nun in 2 Varianten
welches ist die Richtige ?


Die Experten können mich gerne korrigieren.
Ciao
Don Pasquale

[JanHoener]

ich meine nicht, dass hier ein denkfehler liegt. ich meine es nur anders: bei großen datenbanken kommt es schonmal vor, dass z.b. eine person doppelt angelgt wird. also doch redundanz.

aber sehr viel weiter hat es mich nicht gebracht.

trotzdem danke.


gruß jan

[Semeaphoros]

doppeltangelegtepersonensindnichtwirklichredundanzsonderneshandeltsich umdatenduplette nredundanzistnurdannredundanzwenndiedatensichergleichwertigsindundsichdadur chggfergänzenodergegenseitiggegenfehlübermittlungenoderanderefehlerabsichern

[animate]

doppeltangelegtepersonensindnichtwirklichredundanzsonderneshandeltsich umdatenduplette nredundanzistnurdannredundanzwenndiedatensichergleichwertigsindundsichdadur chggfergänzenodergegenseitiggegenfehlübermittlungenoderanderefehlerabsichern

in meinen Augen ist es redundant, wenn die gleiche Information mehrmals vorhanden ist.
Zwei Datensätze, die die gleiche Information enthalten sind daher in meinen Augen redundant.
Ich denke, ob damit gegen irgendwelche Fehler abgesichert wird oder nicht, spielt keine Rolle.

doppelt: in einer View existieren mehrere Dokumente für das gleiche Objekt

noch blöder ist es, wenn die gleiche Information nicht in der selben View (und damit DB) ist, sondern in einer anderen Datenbank, oder sogar in mehreren. In meiner alten Firma nannten wir das Datenbankdschungel. Sehr schwer, zu überblicken.

[Semeaphoros]

in meinen Augen ist es redundant, wenn die gleiche Information mehrmals vorhanden ist.
Zwei Datensätze, die die gleiche Information enthalten sind daher in meinen Augen redundant.
Ich denke, ob damit gegen irgendwelche Fehler abgesichert wird oder nicht, spielt keine Rolle.

Richtig, sofern die Information eben gleich ist, was normalerweise bei zweifacher händischer Eingabe eben nicht gegeben ist. Damit ist das dann so eine Sache mit der Redundanz. Da müsste man dann bereits mit Korrelation arbeiten, wenn man das dann noch verfeinern möchte.

[Driri]

in meinen Augen ist es redundant, wenn die gleiche Information mehrmals vorhanden ist.
Zwei Datensätze, die die gleiche Information enthalten sind daher in meinen Augen redundant.
Ich denke, ob damit gegen irgendwelche Fehler abgesichert wird oder nicht, spielt keine Rolle.

Sehe ich auch so. Ich denke auch, es ist eher die Frage, wo machen Redundanzen Sinn ?

In einer Notesanwendung komme ich doch meist gar nicht um Redundanzen herum bzw. Notes erzeugt ja systembedingt selber Redundanzen (Replizier- und Speicherkonflikte).

Redundanzen in Notes sind nicht nur doppelte Dokumente, sondern auch doppelte Informationen in unterschiedlichen Dokumenten (z.B. Anschrift einer Firma, die sowohl im Stammdaten-Dokument der Firma, als auch in einem Mitarbeiter-Dokument zur Firma hinterlegt sind). Das läßt sich sinnvoll auch gar nicht vermeiden, sonst müßte man anfangen Relationen nachzubilden und z.B. per @DBLookup sind das dann echte Performancekiller.

[Semeaphoros]

Gut, das kann man natürlich. Nur wird man dann nicht darum herum kommen, zwischen guter und schlechter, zwischen nützlicher und schädlicher Redundanz (ums mal etwas einfach auszudrücken) zu unterscheiden und damit macht man sich eigentlich das Leben eher etwas schwerer als nötig.

Nimmt man - für die Informationstheorie brauchbare - Redundanzdefinition hier: http://goethe.ira.uka.de/seminare/redundanz/ dann fallen Duplikate eben nicht mehr unter die Redundanz, denn das ist keine zusätzliche Information mehr.

Nur so als Denkanstoss .....

[Driri]

Ich neige eher dazu, Dinge aus der Praxis zu sehen, statt aus der Theorie. Irgendwelche theoretischen Definitionen sind ja schön und gut, aber das kann man IMO eh nur als Richtlinie nehmen. Oftmals ist die Theorie einfach zu weit von der Praxis entfernt 

[Semeaphoros]

Hmm, erstens, offenbar gehts um eine Seminararbeit, also um Theorie, zweitens ist gerade in der Praxis der Unterschied zwischen echter Redundanz und Datendupletten uU entscheidend für den Erfolg ... ok, das bekommt man vor allem in der relationalen Welt zu spüren, bei uns weniger .....

[JanHoener]

Gut, das kann man natürlich. Nur wird man dann nicht darum herum kommen, zwischen guter und schlechter, zwischen nützlicher und schädlicher Redundanz (ums mal etwas einfach auszudrücken) zu unterscheiden und damit macht man sich eigentlich das Leben eher etwas schwerer als nötig.

Aber genau darum geht es ja. Ich suche doch verschiedene Ausprägungen und Eigenschaften der Redundanz!
Bisher bin ich aber immer noch nicht weiter....:-)

[Semeaphoros]

Da hast Du jetzt aber enorm viele Anregungen bekommen, inklusive einem Link zu ziemlich viel Informationen, da solltest Du mal ans Verdauen und Verarbeiten denken.

[JanHoener]

Also entweder begreif ich es nicht oder ich denk an der Thematik vorbei. Wo habe ich denn Denkanstöße bekommen, bei der es um Redundanzeigenschaften ging?
Den Link, den du mir gegeben hast, kannte ich schon. Dort geht es nicht um Groupware sondern eher um Fehlerkorrektur und Kompression. Das trifft leider nicht mein Thema.

[Semeaphoros]

Na ja, pfannenfertig wirst Du Deine Seminararbeit auch nicht bekommen. Aus dem Text, der zwar an der Thematik vorbei geht, lässt sich aber bestimmt mal herausschälen, was Redundanz ist. Redundanz in Groupware ist nun mal nicht wirklich etwas besonderes. Allerdings ist natürlich die Thematik "Datenbank" dem Thema Groupware bestimmt näher als diese Vorträge. Aber die Essenz wirst Du Dir schon selber "herausdestillieren" müssen.

[JanHoener]

Wisst ihr, ich habe einfach das Problem, folgende Bereiche klar gegeneinander abzugrenzen und auch noch geeignete Unterpunkte dafür zu finden:
1) Eigenschaften von Redundanz
2) Arten von Redundanz
Was sind nun z.B. doppelte Informationen? Eine Eigenschaft oder eine Erscheinungsart?
3) Gründe für Redundanz
Ist eine gewollte Redundanz eine Eigenschaft oder packe ich sie lieber zu den Gründen für Redundanz, da sie eine Folge von Repliken ist.
4) Folgen von Redundanz
5) Identifikation von Redundanz


Ich dreh mich hier die ganze Zeit im Kreis. Ist echt langsam nervig, nicht zu wissen, wo was hinkommt.
Mein Betreuer drückt sich leider nicht klar aus. Wenn ich ihn diese Fragen frage, sagt er immer, es kommt aufs Modell an!?!
Bitte helft mir.
Danke...

[Marinero Atlántico]

Ich würd ein bischen anders vorgehen.
Ganz zu Anfang steht die Einleitung. Die schreibst du ganz zu Schluß.
Ich würd am Anfang erstmal definieren, was allgemeine Definitionen unter Redundanz verstehen (2 Seiten).
Dann eine Diskussion, wo es in Notes systembedingt Punkte gibt, an denen Redundanz auftritt. Dies dann auf die Definition beziehen. 
Also, alter Trick, vom Allgemeinen (allgemeine Redundanz-Definitionen) ins Spezielle (Redundanz in Notes) übergehen. Z.B. auch Unterschied zwischen Speicher- und Replizierkonflikt erklären (3 Seiten).
Dann die Folgen der Redundanz, die nicht nur positiv sind und wie man sich dagegen schützt bzw. damit umgeht.  Gibt z.B. auch eine Möglichkeit sich zumindest gegen Speicherkonflikte durch programmatisches Locking zu schützen (4 Seiten).
Am Ende noch ein Schluß (0.5 Seiten).

Axel

[Semeaphoros]

Axel, warum nennst Du das "alter Trick"? Das ist doch das seit eh und je empfohlene allgemeine Muster (oder sag dem Pattern, wenn Dir das lieber ist ).

Jan: ich denke mal, der Betreuer will genau das von Dir und nicht von uns haben. Und wenn Du Dir Deine Arbeit von jemand anderem schreiben lassen willst, dann gehe davon aus, dass Dein Betreuer das merkt und darauf entsprechend reagieren wird.

[Gandhi]

Also ich finde die Gliederung ganz gut. Wenn Du dann noch Informationen  von Daten abgrenzt und das Ganze mit Inhalt füllst sollte das schon werden.
1.) Würde ich vielleicht in 'Was ist Redundanz' umändern, was natürlich die Eigenschaften einschließt aber irgendwie verständlicher ist (für mich zumindest)
3.)würde ich in Ursachen von Redundanz umbenennen, wobei 4.) diesen Punkt dann logisch komplettiert (und evtl. schon in 3. einbezogen werden sollte).
Ansonsten fehlt evtl. noch ein Punkt 'Entfernen ungewünschter Redundanz'
Eine Frage noch: Bezieht sich das Thema strikt auf Notes oder auf beliebige datenhaltende Systeme?

Den Inhalt der einzelnen Punkte überlasse ich aber auch Dir - sollst ja bei so einer Arbeit auch denken/forschen lernen...