AUGIAS-Data Anwenderforum

Hallo,

Habe mich heute ein wenig in der Datenbankstruktur umgesehen und voller Schrecken festgestellt das sie kaum normalisiert ist und auch etwas grosszügig mit dem speicherplatz umzugehen scheint.
anyways..

es würde mich interessieren ob es irgendeine art von dokumentation bezüglich dem manuellen hinzufügen (eigenes script) von objekten in die datenbank gibt.

Falls nicht, wie ist das mit dem (Massen-)Importieren (z.B. OCR gelesener Inhalte) verschiedener/mehrerer felder via .cvs?
Sprich: Mehrere Felder als auch mehrere Objekte auf einmal. (Wofür ich ein script erstellen würde.. aber wenn's mit cvs files auch funktioniert....)

Danke im Voraus.
mfg,
-Alex

Von welchem Programm sprechen Sie?
Es gibt mehrere Programme, das Ganze mit unterschiedlichen Datenbank-Backends und in verschiedenen Datenbank-Versionen.
Da fällt es jetzt schwer, etwas Konkretes auf Ihre Frage zu antworten
Was meinen Sie mit kaum normalisiert und in wie fern wird großzügig mit Speicherplatz umgegangen?




Für einige Programme von denen gibt/gab(?) es ein konfigurierbares Import-Tool für diverse Datenformate. Das ist sicherlich weniger riskant als auf eigene Faust dort Daten rein zu schreiben.
Für einmalige Fremddatenimporte bietet Augias meines Wissens immer noch einen aufwandsabhängigen Konvertierungsservice an. Haben wir damals beim Umstieg auf Augias auch in Anspruch genommen. Würde da einfach mal anfragen.




CVS? Das verstehe ich jetzt nicht. Ist ein Versionierungssystem (-> CVS) zur Verwaltung von unterschiedlichen Bearbeitungsständen der Daten geplant bzw sollen Daten aus einem solchen System importiert werden?

Gruß,
Archi

Oh my... Mal danke für die Antwort; dann: Sorry!!
War gestern sichtlich ein langer Tag.

Ich meinte Augias Museum4, sowie Comma separated value files (.csv).. (bezugnehmend auf: http://www.augias.de/forum/showthread.php?tid=33)

Re: Datenbank-normalisierung..
Es würde den Rahmen dieses Forums sprengen wenn ich jetzt ins Detail gehe aber hier ein netter link: http://en.wikipedia.org/wiki/Database_normalization
und doch ein kleines Detail (für interessierte): "redundanz"
PS: Die grosszügigkeit wird durch (fehlende) normalisierung impliziert.

Und zur weiteren Klarstellung:

Ich habe das Handbuch des ImportTools durchgesehen, habe die Import funktionen von Museum4 selbst angesehen, werde aber definitiv mehr Funktionalität brauchen.

Darum meine Frage, gibt es eine Dokumentation für die Datenbankstruktur selbst, eine Anleitung für manuellen Import oder ähnliches?

PPS: "Konvertierungsservice" is out of the question

lg,
-Alex

Ah, Museum4. Hab' ich schon mal auf der Archivistica gesehen, kenne es aber nicht genau. Dürfte ein ähnlich komplexes Tabellensystem besitzen, wie Archiv8. Hochachtung! (dafür dass Ihnen "ein wenig in der Datenbankstruktur umsehen" schon derarige Aussagen über die Datenstruktur ermöglicht).




CSV ist mir als Begriff auch schon untergekommen und ich hatte auch erst daran gedacht, dass dies gemeint gewesen sein könnte, nur ich dachte dann: Als Datenbank-Profi hätte er sicher nicht CVS geschrieben, wenn er CSV gemeint hätte und habe dann nachgeschlagen, was CVS ist.




Vielen Dank für den Link. Da dies ein vorwiegend deutschsprachiges Forum ist, will ich den analogen Link zum deutschen Wiki-Artikel an dieser Stelle ergänzen.

Ich weiss schon in etwa was mit "Normalisierung" gemeint ist, fragte aber wegen der pauschalen Aussage "kaum normalisiert" rück.
Ohne jetzt alles in den Artikeln verstanden zu haben, erkenne ich doch das wieder, was mir unser IT-ler, den ich heute extra dazu befragt habe, auch erklärt hat:

Ein Normalisierungs-Imperativ sei was für Akademiker im Elfenbeinturm, die nie im Leben eine praxisorientierte Anwendung geschrieben haben.
(Sei auch bisweilen bei Informatikstudenten nach einigen Vorlesungen über Codd'scher Datenbanktheorie anzutreffen)
Das Datenmodell soll in erster Linie den realen Anwendungsfall möglichst gut wiedergeben. Redundanzen sind dabei häufig gewollt um eine praxisgerechte Arbeitsgeschwindigkeit zu gewährleisten. Redundanzen sind offenbar nicht pauschal böse. Um eine vermeintliche Redundanz als tatsächliche Redundanz zu erkennen, um dann eine seriöse Aussage über die Güte des Normalisierungsgrad machen zu können, müsste man den Geschäftsvorgang, den die Datenstruktur widerspiegelt, zunächst verstanden haben.

Mir fällt dazu ein:
Wenn man das Modell aber verstanden hat, müsste man sich nicht um eine Datenmodell-Dokumentation bemühen und wüßte wie die Daten zu integrieren wären.
Sie verstehen, was ich meine? Hint: Falsche Reihenfolge bezüglich der Aussage über den Normalisierungsgrad und dem Einholen von Informationen




Ok, habe grade mal nachgeschaut: Das Import-Tool unterstützt tatsächlich nur wesentliche Datenstrukturen, einige Spezialitäten bleiben unberücksichtigt. Ich weiss zwar nicht was Sie speziell an "mehr Funktionalität brauchen", aber ich kann mir nicht vorstellen, dass die Programm-eigene Importschnittstelle in ihrem eigenen Austauschformat etwas nicht unterstützt. Das kann nicht sein, da die Augias-Programme (wird bei Museum nicht anders sein) diese Schnittstelle für den Import/Export zwischen den eigenen Datenbanken nutzt. Das könnte dann ja nicht funktionieren.




Schon mal mit dem speziellen Import-Anliegen an einen Techniker der Firma heran getreten? Vielleicht sogar ohne diesen vorher mit Ihrer Meinung über die Sinnhaftigkeit der benutzten Datenschemata zu erfreuen?

Kann es sein das ich hier nicht zufällig eine deftige Portion Sarkasmus herauslese?
Klarstellung: In der Haupt-table die die eigentlichen Objekte speichert gibt es (nicht sicher wie viele genau) sehr viele Felder die im "0-815 Betrieb" leer bleiben, sprich verschwendeter speicherplatz sind (Datenbanken reservieren normalerweise den von einem Feld verbrauchten Speicherplatz, auch wenn er nicht verwendet wird!).
Mir ist durchaus klar das in einer REALEN Anwendung die Theorie der Normalisierung oft ("öfter" jedoch aus kosten- als aus irgendwelchen anderen gründen eher hinder- als förderlich ist.

Jedoch sehe ich !gerade! bei Archivierungs-Software (die in den allermeisten fällen SEHR grosse Datenmengen zu verarbeiten hat) keinen grund Speicherplatz zu belegen der nur gebraucht wird wenn das "Formular" ihn auch benutzt (was in den allerwenigsten fällen der fall sein sollte).
Da Normalisierung eigentlich verwendet wird um eben solches zu verhindern, erwähnte ich es nicht aus blindem Effizienzwahn heraus, sondern als konstruktive Kritik.
Denken sie ich würde mich über Manuellen Import informieren wenn ich die Software für "so schlecht" hielte wie sie es (meiner Meinung nach) zu implizieren scheinen?
Abgesehen davon habe ich weder die 4te Normalisierungsform erwähnt/gemeint, noch von Imperativen gesprochen.
Ich sehe solcherlei Theorien als gute Hilfmittel der Qualitätssicherung!

Jedoch: Ohne hier irgend etwas runtermachen zu wollen möchte ich Ihrem "IT-ler" ans Herz legen doch mal auszurechnen wieviel Platz verloren geht wenn man ein Formular mit 10 Feldern hat, die Tabelle aber ~50 Felder (bezieht sich jetzt nicht unbedingt auf die genannte app da ich die tatsächliche anzahl der felder nicht mehr im Kopf habe) pro row vorsieht; und v.a. ob es bei aller praxisnähe effizient ist nur 20% der Felder pro Eintrag zu nutzen.
Bei aller liebe zur "Realität".. das "muss" nicht sein und lässt sich auch mit recht einfachen relationalen tabellenstrukturen verhindern. (und auch erweitern, denn wenn ich mich nicht irre ist die Anzahl der Felder pro Formular in oben erwähnter Datenbankstruktur begrenzt (was sie nicht sein müsste))


hehe.. verzeihen sie meinen durch übernachtigkeit verstärkten menschlichen hang zu (flüchtigkeits-)fehlern. Ich verwende csv files so gut wie nie, cvs aber doch fast täglich..


Eben! siehe oben^^

So etwas nenne ich eine Hypothese (kein Argument), welche ohne spezifische Relevanz auch recht unbeweissbar ist.


Was ich auch nicht gesagt habe.
Keine Ahnung wo diese defensive haltung ihrerseits begründet liegt.
Fakt ist das ich "Schrecken" geschrieben habe.
Nicht "Böse", nicht "Schlecht", nicht "Falsch", nicht "Nutzlos"...
Einfach nur unerwartet (wie oben (siehe Datenmengen) beschrieben).


Auch das ist (mir) eine viel zu generische Aussage..
Hier etwas spezifisches: Ich habe ein Formular erstellt, Datensätze eingefügt und dann voller !!schrecken!! mehr als die Hälfte der Felder (in der objekt-tabelle) als NULL (leer) gesehen. (was wie bereits erwähnt (oh heilige redundanz!) nicht nötig ist)


Oh und wie ich sie verstehe.. siehe "Hier etwas spezifisches".
Ich sehe keinen logischen Grund alle facetten eines systems durchschaut haben zu müssen um offensichtliche "schwachstellen" (bitte nicht wieder als angriff auffassen; I LOVE MUSEUM4 (after all; it saves my day)) zu erkennen.


z.B.:
lookup funktionen um gleichzeitige INSERT's sowie UPDATE's (oder DELETE's) zuzulassen, (Automatisierung zur Steigerung der Effizienz im Umgang mit Zeit)
oder:
detailierte Dokumentation der Datenbankstruktur wäre ein MUSS für die Programmierung eines Clients der meinen Kollegen die Möglichkeit eröffnet mit nur "2 Mausclicks" (und nur einer einzigen applikation) einen Datensatz (z.B. aus einem OCR gelesenem Bild) zuerst zu überprüfen um sie dann, ohne grossartige copy&paste routinen, in die Datenbank einzufügen..


Ich wollte (da ich (noch) keinen Zeitdruck habe) zuerst versuchen unter den Anwendern Infos und/oder Meinungen einzuholen.
Allenfalls hoffe ich doch das besagter Techniker zwischen konstruktiv gemeinter Kritik und Zweifel an der Sinnhaftigkeit seiner Arbeit unterscheiden kann.

mfg,
-Alex