Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Manueller Import
#1
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
Zitieren
#2
josephinum schrieb: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..

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 Wink
Was meinen Sie mit kaum normalisiert und in wie fern wird großzügig mit Speicherplatz umgegangen?

Zitat: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.

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.

Zitat: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....)

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
Zitieren
#3
Oh my... Mal danke für die Antwort; dann: Sorry!!
War gestern sichtlich ein langer Tag. Rolleyes

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 Smile

lg,
-Alex
Zitieren
#4
josephinum schrieb:Ich meinte Augias Museum4,

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).

Zitat: sowie Comma separated value files (.csv)..

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.

Zitat: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"

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) Wink
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 Wink

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

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.

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

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? Toungue
Zitieren
#5
Archivmedes schrieb:Hochachtung! (dafür dass Ihnen "ein wenig in der Datenbankstruktur umsehen" schon derarige Aussagen über die Datenstruktur ermöglicht).
Kann es sein das ich hier nicht zufällig eine deftige Portion Sarkasmus herauslese? Smile
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 Wink 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? Smile
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))

Archivmedes schrieb: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.
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..

Archivmedes schrieb:Das Datenmodell soll in erster Linie den realen Anwendungsfall möglichst gut wiedergeben.
Eben! siehe oben^^
Archivmedes schrieb:Redundanzen sind dabei häufig gewollt um eine praxisgerechte Arbeitsgeschwindigkeit zu gewährleisten.
So etwas nenne ich eine Hypothese (kein Argument), welche ohne spezifische Relevanz auch recht unbeweissbar ist. Smile

Archivmedes schrieb:Redundanzen sind offenbar nicht pauschal böse.
Was ich auch nicht gesagt habe. Sad
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).

Archivmedes schrieb: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.
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)

Archivmedes schrieb: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?
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.

Archivmedes schrieb: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"
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..

Archivmedes schrieb: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? Toungue
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. Toungue

mfg,
-Alex
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste