Das Notes Forum
Sonstiges => Offtopic => Thema gestartet von: JanHoener am 09.04.05 - 12:20:21
-
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
-
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
-
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
-
@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
-
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
-
doppeltangelegtepersonensindnichtwirklichredundanzsonderneshandeltsich umdatenduplette nredundanzistnurdannredundanzwenndiedatensichergleichwertigsindundsichdadur chggfergänzenodergegenseitiggegenfehlübermittlungenoderanderefehlerabsichern
-
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.
-
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.
-
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.
-
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 .....
-
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 ;)
-
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 .....
-
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....:-)
-
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.
-
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.
-
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.
-
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...
-
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
-
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.
-
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...
-
Dieses ganze Schreiben von Hausarbeiten geht eigentlich hauptsächlich darum, dass du lernst, den Text entsprechend zu strukturieren.
Falls du damit Schwierigkeiten hast (hat jeder zu Anfang) empfehle ich die entsprechende Literatur zu wissenschaftlichen Arbeiten und das Zusammenarbeiten mit anderen.
Diri:
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
Definiere bitte Praxis. Definiere bitte Theorie. Das ist mal wieder so ein bold statement. Es gibt nämlich sehr unterschiedliche Arten von Theorie.
Deine Aussage ist ja letztlich auch eine Theorie.
Es gibt praxisnähere und praxisfernere Theorie, je nach Motivation des Theoretikers. Bin mir z.B. ziemlich sicher, dass Kants "Kritik der reinen Vernunft" irgendwas mit meinem Job zu tun hat. Aber eben sehr entfernt. Bin mir aber z.B. sehr sicher, dass Fowlers, "Patterns of Enterprise Computing" sehr viel mit meinem Job zu tun haben.
Ausserdem basieren viele, sehr viele Dinge die hier diskutiert werden eindeutig letztlich auf theoretischen Studien.
Theorie ist an sich sehr effizient. Das Problem ist nur, dass eindeutig zu viele Leute rumlaufen, die versuchen ihre bold statements mit haarsträubender Theorie zu untermauern.
Empirisch fundierte Theorie ist ja immer va. auch der Versuch, die wichtigsten Punkte aus der empirischen Wirklichkeit (=Praxis) herauszufiltern. Ich mache den umgekehrten Prozeß durch und sehe Theorie als immer wichtiger an. Wichtig ist, dass man die entsprechende Theorie kritisch einordnen kann
-
Meine Aussage bezog sich auf mein vorheriges Statement. Wenn ich mich hier jetzt für alles rechtfertigen muß, nur weil einige Leute hier jedes Wort auf die Goldwaage legen, hab ich keine Lust mehr, mich an Diskussionen zu beteiligen.
Aber Forentrolle muß es wohl überall geben.
-
Jau, das war jetzt beides wirklich nicht nötig, also bitte zurück zum Thema: Redundanz und Seminararbeit.
-
imho kann man so etwas komplexes wie eine Seminararbeit sowieso nicht in einem Internet-Forum absprechen.
Wie gesagt. Der beste Tipp ist imho,
- ein paar Bücher zu wissenschaftlichen Arbeiten lesen.
- Sensibilität für Struktur wissenschaftlicher Texte zu gewinnen, indem du über die Struktur von wissenschaftlichen Texten, die du liest, nachdenkst.
- Struktur, Texte mit anderen durchsprechen/korrekturlesen lassen.
-
ich habe jetzt folgende gliederung:
1. Was ist Redundanz?
1.1. Definition aus Wikipedia
1.2. Arten von Redundanz (verteilt, mehrfache Dokumente, mehrfache Informationen)
1.3. Ursachen von Redundanz
1.4. Folgen von Redundanz (Inkonsistenz) Was könnte ich hier noch Unterbringen? Ich muss auf jeden Fall die Bereiche "doppelte Daten", "fehlerhafte Informationen" und "unvollständige Daten" unterbringen. Diese sind aber nicht unbedingt Folgen von Redundanz? Wo würdet ihr sie einsortieren? Unter Eigenschaften?
1.5. Identifikation von Redundanz
Was meint ihr? In sich schlüssig und gut strukturiert?
Gruß Jan
-
imho kann man so etwas komplexes wie eine Seminararbeit sowieso nicht in einem Internet-Forum absprechen.
Wie gesagt. Der beste Tipp ist imho,
- ein paar Bücher zu wissenschaftlichen Arbeiten lesen.
- Sensibilität für Struktur wissenschaftlicher Texte zu gewinnen, indem du über die Struktur von wissenschaftlichen Texten, die du liest, nachdenkst.
- Struktur, Texte mit anderen durchsprechen/korrekturlesen lassen.
schon klar, nur ist präsentationstermin am 22.04. etwas knapp fürs lesen. deswegen frage ich hier nach eurer meinung, da ihr ja schon erfahrung mit solchen texten habt.
-
Dann ein paar Tips zum Lesen:
Lies folgende Begriffe nach (soweit nötig)
-Replik/Replikation
-Lokale Replik
-Kopie einer Datenbank
-Speicher und Replizierkonflikte
-Verteilte Datenhaltung
-Eindeutigkeit von Adressen im NAB
-Notes-Cluster
-Backup/Recovery
Das sollte so ziemlich alles zum Thema Redundanz in Notes sein (wenn ich nichts vergessen habe - was andererseits ziemlich wahrscheinlich ist...)
Und bis zum 22.4.05 sinds ja noch 10 Tage - das reicht locker für 2000 Seiten Literatur ;D
-
Für mich sieht das nach einer Grundstudiums-Seminararbeit aus, right?
Du hast dir ein bischen wenig Zeit gelassen. Gerade für die ersten Arbeiten sollte man sich viel Zeit lassen. Aber ich hatte auch gerade zu Anfang (und zu Ende) meines Studiums so getürkte Kamikaze-Einsätze.
Geb dir beim nächsten Fall ein wenig mehr Zeit.
Bei so Kamikaze-Arbeiten sollte man alles, was irgendwie negativ aufstössen könnte vermeiden. Also quasi: Catenaccio spielen. Zu null spielen. Oder 4 gewinnt.
Der Punkt "Definition aus Wikipedia" könnte aufstossen. Eigentlich gehören Arten von Redundanz zur Begriffsdefinition. Komplexe Begriffe sollten auch nicht per Definition determiniert werden. Vielmehr ist es vermutlich intelligenter den Begriff ein wenig zu diskutieren. Unterschiedliche, möglicherweise widerstreitende Definitionen vorgestellt. Etc.
Ich bin damit nicht richtig durchgekommen. Aber nochmal:
Erst Begriff von Redundanz (inklusive Aufzählen der unterschiedlichen Orten, wo sie sich manifestiert) und dann aufzeigen, wo diese Redundanz in einem Notes-System auftritt. Moment noch besser: Bestimmte Redundanz Aspekte treten in allen Client-Server Systemen auf. Deshalb das vielleicht erst: Redundanz in Client-Server Systemen und dann Redundanz in Notes!
Es existieren gewisse allgemeine Motivationen für Redundanz in Systemen wo viele Clients auf 1 oder mehrere Ressourcen auf einem Server zugreifen. Das ist ein Knappheitsproblem. Der Server kann nicht eine unbegrenzte Menge an Anforderungen bearbeiten. Ausserdem kann diese Verarbeitung nicht in beliebiger Reihenfolge geschehen. Das muß herausgearbeitet werden.
Neben dieser "Runtime-Redundanz" existiert - gerade im Vergleich zu Relationalen Datenbanken - sowas wie Redundanz im Datenbank-Schema. Relationale Datenbanken sind wesentlich strenger im Hinblick auf Redundanzvermeidung als LotusNotes (oder auch Objektsysteme). Fällt immer wieder auf beim Mapping von Objekten auf Relationale Strukturen, dass die Objekte wesentlich redundanter sind als eben RDBMS.
Motivation von Redundanz ist vielleicht ein besserer Titel als 1.3. Ursachen von Redundanz
Mir fallen ein:
- Performanz (existiert trade-off: Performanz vs. Redundanzfreiheit. Wobei Performanz auch überhaupt kein guter Begriff ist. Scheissendreck. Muss irgendwie in einem Begriffsdreieck: Redundanz. Concurrency. Contention).
- Datenkonsistenz vs. Redundanz. Wenn Daten doppelt gespeichert sind, entsteht automatisch die Gefahr, dass sie inkonsistent werden.
- Transaktionen benötigen imho eine gewisse Redundanz im System. Transaktionen heisst: Mehrere Aktionen werden zu einer atomaren/unteilbaren Aktion zusammengefasst. Der Fall eines Speicherkonflikts:
User A bearbeitet Dokument a.
User B sieht Dokument a in einer Ansicht und öffnet dies ebenfalls zum Bearbeiten. Er erhält keine Nachricht, dass User A es bearbeitet (es gibt bei einem Server programmatische Lösungen damit umzugehen, aber davon sehe ich erstmal ab).
Hier genau bearbeiten, wo eigentlich die Redundanz besteht. Die ist nämlich darin, dass User A auf einer Kopie von Dokument a arbeitet und User B eine andere Kopie des Dokuments a' zum Bearbeiten öffnet.
User A speichert Dokument a.
User B macht auf der alten Kopie von a ein paar Bearbeitungen und speichert das Dokument.
Beide Dokumente sind inkonsistent und es existiert ein Speicher-und-Replizierkonflikt.
-
Das war jetzt eine wirre Ideen-Sammlung, die dich möglicherweise verwirrt.
Wichtigster Tipp: Suche in der Literatur nach Diskussionen, Begriffsdefinitionen zu Redundanz. Beziehe dich auf einen Teil dieser Literatur. Das ist meist ziemlich einfach zu schreiben und beliebt bei Dozenten.
Versuche dann allgemeine Motivationen von Redundanz in Client-Server Systemen und Datenbankschematas zu finden.
Gehe dann auf die Besonderheiten von Lotus Notes ein.
Versuche nicht zu viel Inhalt und Details von Lotus Notes da reinzupacken! Zu sowas neigen Anfänger immer und die meisten Dozenten mögen genau das nicht.
Such dir jemanden, der deine Arbeit querliest.
Ich hab mehr von der extrem nervigen Kritik von meiner Schwester und der Kritik eines ziemlich abgedrehten "wissenschaftsfreak"-Kommilitonen (Jörg) gelernt als von der Uni an sich glaub ich. Jörg ist jetzt glaub ich leider immer noch arbeitslos, aber der Typ hatte in vielen Punkten einfach recht und es hat mir sehr geholfen.
Für die Zukunft: Lese die veröffentlichten Texte desjenigen, der die Arbeit bewertet. Ich hab das erst bei meiner Diplomarbeit gemacht, als ich unter einer leicht assozialen "Zweit-Korrektor" Regelung stand. Mein Erstkorrektor hat mir das empfohlen und das hat sehr geholfen. Bringt aber erst was, wenn man selbst ein paar Arbeiten geschrieben hat.
Gib dir ein bischen Mühe und setze dir vernünftige Fristen! Jörg ist irgendwann dazu übergegangen für Hauptseminarsarbeiten 10 Monate zu benötigen (vorgesehen: 2 Monate). Er hat dann immer ein "Sehr gut" bekommen, aber sich damit zu weit von unserer Gesellschaft entfernt.
Also: Mühe geben, sich interessieren, Termine einhalten, Korrekturlesen lassen, Kritik aushalten.