Hallo Allerseits.
Ich hänge hier gerade an dem Entwurf meiner Datenbank. Und nun stellt sich mir die Frage,
gibt es eine Normung für Datenmodelle?
Grüße und ein guten Rutsch ins Neue Jahr
Josef
Hallo Josef,
aber sicher doch. Es gibt da ein sehr bekanntes Modell für relationale Datenbanken, es nennt sich Entity-relationship-Modell, erfolgt in 3 Schritten, die Endstufe ist die „3. Normalform“ und ist eigentlich sehr einfach zu handhaben.
Für objektorientierte Datenbanken gibt es andere Modelle, da kenne ich mich aber nicht aus, da ich seit 1994 nichts mehr programmiere (damals noch mit Clipper für DOS)
Grüsse
Sven
*dersichgerneanalteComputertageerinnert*
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
gibt es eine Normung für Datenmodelle?
aber sicher doch. Es gibt da ein sehr
bekanntes Modell für relationale
Datenbanken, es nennt sich
Entity-relationship-Modell, erfolgt in 3
Schritten, die Endstufe ist die „3.
Normalform“ und ist eigentlich sehr
einfach zu handhaben.Für objektorientierte Datenbanken gibt es
andere Modelle, da kenne ich mich aber
nicht aus, da ich seit 1994 nichts mehr
programmiere (damals noch mit Clipper für
DOS)
Hallo Sven
zunächst mal Danke für die schnelle Antwort.
Aber ich meinte nicht die überführung in die Normalform, sondern ob es generelle Festlegungen gibt. z.B. eine Adresse hat folgende Merkmale:
Name, Vorname, Straße, PLZ, ORT, …
Also so etwas eine Norm oder ein Standart.
Grüße
Josef
Aber ich meinte nicht die überführung in
die Normalform, sondern ob es generelle
Festlegungen gibt. z.B. eine Adresse hat
folgende Merkmale:
Name, Vorname, Straße, PLZ, ORT, …
Also so etwas eine Norm oder ein
Standard.
Auf der Seite der Datenbank ist eine derartige Normung doch kaum möglich bzw. gar nicht wünschenswert. Schon bei deinem Beispiel „Adresse“ hängt z.B. die Definition des Felds „PLZ“ davon ab, wo und wie deine Datenbank eingesetzt werden soll. Wenn z.B. nur deutsche Adressen vorkommen dürfen, ist eine Beschränkung von „PLZ“ auf ein 5-stelliges Textfeld mit der zusätzlichen Einschränkung auf numerische Zeichen sicher zulässig, bei Auslandspostleitzahlen würde diese Einschränkung zu weit gehen.
Ähnliches gilt z.B. für Straßenanschriften und Postfachanschriften, und den ganzen Bereich „Grosskundenpostleitzahlen“. Dazu gehören schon bei reinen Inlandadressen ein ganzer Haufen zusätzlicher Regeln, die sich allesamt nicht allein durch das Datenbankdesign erschlagen lassen. Im Fall der Adressaufbereitung von Inlandsadressen gibt es z.B. von der Post Vorgaben, wie diese erfolgen sollte. Dabei geht es aber nicht um die interne Speicherung, sondern um die externe Darstellung (was man natürlich nicht vollständig voneinander trennen kann).
Ähnliche „Normen“ gibt es natürlich überall dort, wo Daten ausgetauscht werden - ob es nun die DATEV-Schnittstelle für Buchhaltungsdaten ist oder die Konversion von Audiodaten in MP3-Dateien ist. Dabei handelt es sich aber in aller Regel um Datei- bzw. Stream-Beschreibungen.
Die kann man dann natürlich mehr oder minder auf die zugrundeliegenden Datenbanken abbilden. Wieweit das hilfreich ist, hängt immer vom Einzelfall ab. Meistens ist es aber besser, die Datenbank intern nicht zu weit einzuschränken und die Gültigkeitsprüfung bzw. die Umsetzung der Daten beim Im- bzw. Export zu machen - schon weil die Gültigkeitsprüfung durch die Datenbank meistens zu unschönen Fehlermeldungen und unerwünschten Effekten führt…
Reinhard
Hallo Sven
zunächst mal Danke für die schnelle
Antwort.
Aber ich meinte nicht die überführung in
die Normalform, sondern ob es generelle
Festlegungen gibt. z.B. eine Adresse hat
folgende Merkmale:
Name, Vorname, Straße, PLZ, ORT, …
Also so etwas eine Norm oder ein
Standart.Grüße
Josef
Hallo Josef,
wenn Du in der Richtung was findest, dann teile es mir bitte mit, würde mich auch sehr interessieren (bisher hatte ich nur Datenbanken mit technischem Inhalt, keine kaufmännischen Daten).
Danke im Voraus.
Sven
Auf der Seite der Datenbank ist eine
derartige Normung doch kaum möglich bzw.
gar nicht wünschenswert.
Wünschenswert wäre es allemal, zumindest auf internationaler Ebene. Wer kennt schon alle Adressangaben, aller Länder. Hier wäre doch eine Art Normung sinnvoll.
Sicher hast Du auch Recht, wenn Du sagst, daß man immer den Einzelfall (also die spezielle Anwendung) sehen muss.
Wenn z.B. nur deutsche Adressen
vorkommen dürfen, ist eine Beschränkung
von „PLZ“ auf ein 5-stelliges Textfeld
mit der zusätzlichen Einschränkung auf
numerische Zeichen sicher zulässig, bei
Auslandspostleitzahlen würde diese
Einschränkung zu weit gehen.
Eben.
Ähnliches gilt z.B. für
Straßenanschriften und
Postfachanschriften, und den ganzen
Bereich „Grosskundenpostleitzahlen“. Dazu
Hier sehe ich noch die geringsten Probleme.
gehören schon bei reinen Inlandadressen
ein ganzer Haufen zusätzlicher Regeln,
die sich allesamt nicht allein durch das
Datenbankdesign erschlagen lassen.
Aber durch die Datenbank vollständig abgedeckt werden sollten, so das sie sowohl eindeutig als auch eine hohe Redundanz aufweisen.
Dabei geht es aber nicht um die interne
Speicherung, sondern um die externe
Darstellung (was man natürlich nicht
vollständig voneinander trennen kann).
Eben.
DATEV-Schnittstelle für Buchhaltungsdaten
Greift zu kurz, aber guter Hinweis.
Meistens ist es aber besser, die
Datenbank intern nicht zu weit
einzuschränken und die Gültigkeitsprüfung
bzw. die Umsetzung der Daten beim Im-
bzw. Export zu machen - schon weil die
Gültigkeitsprüfung durch die Datenbank
meistens zu unschönen Fehlermeldungen
und unerwünschten Effekten führt…Reinhard
Lieber Reinhard
Vielen Dank für Deine Tips aus der Praxis.
Ich werde mir also meine eigenen Modelle basteln, so daß diese nach meinen bisherigen Erfahrungen alles abdecken, aber (z.B. über Texfelder „Bemerkung“, etc) fexibel genug bleiben damit noch nicht erkennbare Anforderungen erfüllt werden können. Eingabe, Import etc. werden dann entsprechende Fehlerchecks enthalten, was sowieso vorgesehen war.
Noch mal vielen Dank an Reinhard und an Sven
Josef
Wünschenswert wäre es allemal, zumindest
auf internationaler Ebene. Wer kennt
schon alle Adressangaben, aller Länder.
Hier wäre doch eine Art Normung sinnvoll.
Dann wäre die „Normung“ sozusagen der grösste gemeinsame Nenner - den kann man doch aber auch selbst schaffen: Einfach alle Felder als Textfelder maximaler Länge anlegen (so gehen übrigens Adressverwaltungsprogramme wie Cobra vor).
Der Teufel steckt aber ja - wie schon gesagt - weniger in den Tabellendefinitionen als vielmehr in der dahinter steckenden Programmlogik.
So ist z.B. die Postleitzahl eigentlich redundant, da sie aus Ortsname und Strasse/Hausnummer erschlossen werden kann.
Wenn man aber tatsächlich die Postleitzahl aus der Tabelle herausnormalisiert, bekommt man echte Probleme.
In den Niederlanden ist’s übrigens umgekehrt, da kann man Ort und Strassennamen aus der Postleitzahl ableiten.
Reinhard
Es könnte interessant sein, sich die EDIFACT-Syntax (Electronic Data Interchange for Administration, Commerce and Transport) zu eigen zu machen (darüber habe ich meine Diplomarbeit geschrieben). Dort wird z.B. international festgelegt, dass die PLZ 10 alphanumerische Stellen hat. Dieses Feld darf z.B. in einem elektr. Handelsdokument mehrmals vorkommen, die Interpretation hängt davon ab, an welcher Stelle dieses Feld kommt. Namesfelder (Vorname, Zuname, Strasse, Ort etc.) sind auf 35 Zeichen begrenzt. Ich selber setzte diese Werte in meinen Datenbanken ein. Sie haben im Bedarfsfall den Vorteil, dass der Datenaustausch automatisiert werden könnte.
Für EDIFACT ist das DIN zu kontaktieren (oder der Beuth-Verlag), irgendwo im Netz gab es eine Software namens EDI-TIE (m.W. aus Holland), mit der man Dokumentstrukturen aus vorhandenen Nachrichtentypen selbst ableiten kann. Auch wenn man das nicht braucht, finden sich dort die Syntax-Beschreibungen.
MfG
Christian
In Zukunft läuft der Austausch vermutlich über XML ab (Meta-Tags je Info-Einheit).
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Es könnte interessant sein, sich die
EDIFACT-Syntax (Electronic Data
Interchange for Administration, Commerce
and Transport) zu eigen zu machen
(darüber habe ich meine Diplomarbeit
geschrieben). Dort wird z.B.
international festgelegt, dass die PLZ 10
Für EDIFACT ist das DIN zu kontaktieren
(oder der Beuth-Verlag), irgendwo im Netz
gab es eine Software namens EDI-TIE (m.W.
aus Holland), mit der man
Dokumentstrukturen aus vorhandenen
Nachrichtentypen selbst ableiten kann.
Auch wenn man das nicht braucht, finden
sich dort die Syntax-Beschreibungen.
Vielen Dank Christian. So etwas hatte ich mir vorgestellt. Außerdem hätte es mich wirklich gewundert, wenn es für die üblichen Daten wie Adressen, etc. keinen Standard geben würde.
Grüße
Josef
Hallo,
mir fällt dazu gerade noch ein, dass man bei der Adresse bedenken sollte, dass sie in einem Anschriftenfeld eines Briefes gedruckt wird. Da passen nur etwa ca. 40 Zeichen herein. Lässt man den Benutzer mehr erfassen, macht der das auch 
.
Es ist im Fall von Firmennamen hilfreich, ein Feld mit 35 Zeichen zu definieren (Briefanschrift) und dazu ein Feld mit großer Länge (z.B. 150 Zeichen) für die volle, korrekte Firmenbezeichnung. Für Vor- und Zuname gilt zwar auch je max. 35 Zeichen, aber 70 Zeichen zusammen kommen so oft wohl nicht vor.
Christian
Vielen Dank Christian. So etwas hatte ich
mir vorgestellt. Außerdem hätte es mich
wirklich gewundert, wenn es für die
üblichen Daten wie Adressen, etc. keinen
Standard geben würde.
Grüße
Josef