Grundlagen einer Datenbank

[net-tobi]

Hallo Forumgemeinde

ich möchte hier einmal einen Beitrag eröffen in den es um die Grundlagen in der Datebank geht.

Ich selbst verwalte eine Datenbank, und habe auch schon eine in Access mit VBA erstellt. Gebe auch gerne zu das ich neuling bin in diesen Bereich.

Deswegen würde es mich intressieren was die Profis unter euch dazusagen.

Werde einfach mal ein paar Aussagen die ich gehört und gelesen habe hier einstellen und mal schauen was ihr dazu meint.

1 Ein Datenbank enthält Beziehungen die Sinnvoll sind und somit doppelte Einträge vermeiden

2 Die Felder einer Datebanken sollten nach den bedürfnissen Konfiguriert sein also z.B. Datumsfelde hier so einstellen das ein Datum und nicht die PLZ aufgenommen wird

3 Die Hardware der Maschine sollte immer sehr großzügig parametriert sein

So das wären nun mal die Aussagen. Bin auf einen offen Diskusson gespannt

Bis dann schönen Tag noch

net-tobi

[flashpixx]

1 Ein Datenbank enthält Beziehungen die Sinnvoll sind und somit doppelte Einträge vermeiden

So pauschal und vereinfacht kann man das nicht sagen. Hier solltest Du Dich über ERM/ERD informieren

2 Die Felder einer Datebanken sollten nach den bedürfnissen Konfiguriert sein also z.B. Datumsfelde hier so einstellen das ein Datum und nicht die PLZ aufgenommen wird

Auch hier gebe ich Dir den Hinweis auf "Normalisierung"

3 Die Hardware der Maschine sollte immer sehr großzügig parametriert sein

Diese Aussage halte ich für falsch, denn z.B. SQLite benötigt keine besondere Hardware.

Diese Frage kann man pauschal nicht beantworte, es kommt auf das DBMS und eben die konkrete Problemstellung an. Man kann ein DBMS von einer einzelnen Datei bis zu einem Cluster mit Loadbalcing und verteilten DBs erstellen

[net-tobi]

Hallo

danke für die schnelle Antwort.

Wenn ich das richtig verstehe dann heißt es doch in den Lehrbüchern immer man sollte doppelt Eintragungen vermeiden!

Also sollte dies über die zerlegung und Beziehungen von Tabellen erreicht werden.

Hoffe habe das mit der Normalisierung so richtig verstanden.

Kurz noch doof gefragt was ist ERM/ERD habe da was in wiki gefunden bin mir aber nicht sicher ob das das ist was du gemeint hast.

Artikel bei Wiki ERM Entity-Relationship-Modell.

Danke im voraus

Schönen Abend noch

net-tobi

[Sarene]

so einfach ist die Normalisierung nicht.

Hier sind die Regeln:

1.Normalisierung:

die Attribute dürfen nur atomar sein (ein Attributwert soll nicht aus 2 Werten bestehen:

falsch: | Strasse 12|

richtig: | Strasse | 12 |

2. Normalisierung

-wenn die 1.Normalisierung realisiert wurde und ein Nicht-Schlüsselattribut voll funktional abhängig von einem Schlüsselattribut ist

z.B.In der Tabelle Kunde ist das Attribut Telefonnummer voll funktional abhängig vom Primärschlüssel Kundennr und von keinem anderen Attribut.

3. Normalisierung

- wenn die 2. Normalisierung vorliegt und ein Nicht-Schlüsselattribut NICHT transitiv abhängig von einem Schlüsselattribut ist.

Transitiv abhängig heißt: Stell dir vor es sind 3 Attribute in einer Tabelle Mitarbeiter:

Primärschlüssel MitarbeiterID, AbteilungsID und Abteilungsname

wenn diese Attribute in einer Tabelle sind, dann ist der Abteilungsname indirekt (transitiv) abhängig vom Primärschlüssel MitarbeiterID, weil die AbteilungsID abhängig vom Primärschlüssel MitarbeiterID ist und der Abteilungsname abhängig von der AbteilungsID ist.

Soll heißen: der Attributname ist eigentlich garnicht von dem Primärschlüssel MitarbeiterID abhängig, sondern nur von der AbteilungsID, weswegen eine neue Tabelle "Abteilung" gebildet werden muss. Die Tabelle enthält die Atributte AbteilungsID und Abteilugnsname. Nun ist der Abteilungsname nicht mehr transitiv abhängig vom Primärschlüssel MitarbeiterID. Die 3. Normalisierung liegt vor.

DAS ERM beschreibt die Tabellen und deren Kardinalitäten (Beziehungen) zueinander. Dafür solltest du die Beziehungsarten 1:1, 1:n und n:m unterscheiden können.

---------------------

zu deinem Punkt1

Ein Datenbank enthält Beziehungen die Sinnvoll sind und somit doppelte Einträge vermeiden

Das fällt unter die Begriffe Referentielle Integrität und Redundanzen.

---------------------

zu deinem Punkt2

2 Die Felder einer Datebanken sollten nach den bedürfnissen Konfiguriert sein also z.B. Datumsfelde hier so einstellen das ein Datum und nicht die PLZ aufgenommen wird

Die Attributtypen sollen so gewählt werden, dass nicht zuviel Speicher verbraucht wird.

-----------------

Bearbeitet 20. April 2010 von Sarene

[flashpixx]

@Sarene: Verende bitte die Quote-Funktion des Forums !

so einfach ist die Normalisierung nicht. [...]

@Sarene: Es gibt mehr als nur 3 Normalisierungsformen, wenn Du sie nennst, dann solltest Du auch wenigstens alle kurz ansprechen

@OP: siehe Normalisierung (Datenbank) ? Wikipedia

Ich denke die BCNF sollte man sich auch noch anschauen, wenn man Normalisierung behandelt

DAS ERM beschreibt die Tabellen und deren Kardinalitäten (Beziehungen) zueinander. Dafür solltest du die Beziehungsarten 1:1, 1:n und n:m unterscheiden können.

Nein !

Das Modell hat in keiner Weise etwas mit Tabellen zu tun ! Das Modell ist besteht aus mehreren Entities und Beziehungen die man strukturiert (auch das ist jetzt sehr flach formuliert). Das ER-Diagramm stellt dann eine Visualisierung des ER-Modells dar.

@OP: siehe Entity-Relationship-Modell ? Wikipedia

Das fällt unter die Begriffe Referentielle Integrität und Redundanzen.

@Sarene: Erkläre einmal bitte wie Du bei einer Generalisierung eine xor-Beziehung nach der Normalisierung umsetzt. Z.B. Person ist Generalisierung von Schüler und Lehrer, eine Person darf aber nur Lehrer oder nur Schüler sein.

Die Attributtypen sollen so gewählt werden, dass nicht zuviel Speicher verbraucht wird.

@Sarene: Definiere einmal bitte präzise "nicht zuviel". (Man kann linguistische Begriffe auch präzise mathematisch / informatisch definieren)

[Sarene]

Hallo Flashpixx,

erstmal danke für deine Anregungen. Irgendwie habe ich das Gefühl, dass du einen schlechten Tag hast heute?

@Sarene: Es gibt mehr als nur 3 Normalisierungsformen, wenn Du sie nennst, dann solltest Du auch wenigstens alle kurz ansprechen

Die ersten 3 Normalisierungsformen sind erstmal die wichtigsten... Ich wollte nicht noch mehr Verwirrung stiften...Wenn du sie erläutern möchtest, bitte!

Nein !

Das Modell hat in keiner Weise etwas mit Tabellen zu tun ! Das Modell ist besteht aus mehreren Entities und Beziehungen die man strukturiert (auch das ist jetzt sehr flach formuliert). Das ER-Diagramm stellt dann eine Visualisierung des ER-Modells dar.

wenn man etwas "flach formuliert", damit es auch Nicht-Datenbankprofis verstehen sollen, dann können einem manchmal die falschen Begriffe rausrutschen. Entschuldigung! Mein Ziel war übrigens nicht bis ins kleinste Detail zu gehen. Der Beitrag war eh schon lang genug.

@Sarene: Erkläre einmal bitte wie Du bei einer Generalisierung eine xor-Beziehung nach der Normalisierung umsetzt. Z.B. Person ist Generalisierung von Schüler und Lehrer, eine Person darf aber nur Lehrer oder nur Schüler sein.

was soll das jetzt?

@Sarene: Definiere einmal bitte präzise "nicht zuviel". (Man kann linguistische Begriffe auch präzise mathematisch / informatisch definieren)

kann man...wollte ich aber nicht, damit es allgemein verständlich bleibt.

[allesweg]

@"nicht zu viel Speicherplatz verbrauchen!" kann zu großen Problemen führen - hier nur simple Beispiele der letzten Jahre: das W2K-Problem, Begrenzung der PLZ auf 4 Stellen und die Einführung der 5-stelligen PLZ 1993 in Deutschland, ...

@Gültigkeiten/Feldtypen: Eine PLZ ist nicht zwingend rein numerisch, nicht jede Adresse muss eine PLZ haben...

[flashpixx]

Ich ergänze einmal zu allesweg: Das Jahr-2000-Problem beruht letztendlich auch darauf, dass man Speicherplatz sparen wollte.

Außerdem würde ich gerne einmal wissen, wie Du "zu viel Speicherplatz" anhand einer Datenbank konkret definieren würdest bzw. wie Du es abschätzt

[Corto -sX-]

ich stelle mal die Frage in den Raum was es dem Threadersteller nutzt wenn ihr hier Spitzfindigkeiten ausdiskutiert?

wobei mich das generalisierungs-ding nun aber doch interessiert. ist mir nie begegnet so ein fall.

kannst du das evtl erläutern, flashpixx?

[flashpixx]

wobei mich das generalisierungs-ding nun aber doch interessiert. ist mir nie begegnet so ein fall.

Gerne: Also man kann das ERM ähnlich wie unter UML als OOP Struktur entwickeln, das findet sich dann in der Literatur meist unter EERD. Damit lassen sich dann eben auch Generalisierungen modellieren. Ich denke die einfachste Vorstellung ist, wenn man die DB nicht als ERD sondern als UML modelliert, d.h. klassenartig so dass Attribute die Eigenschaften werden und Trigger z.B. die Methoden. Meistens verzichtet man dann auf die Sichtbarkeiten.

Das Problem setzt bei der Normalisierung ein, wenn man nun eben ein solches UML in ein RDBMS zu überführen, denn wie baut man z.B. aus einer "abstrakten Klasse / Entity" nun eine Tabelle. Ebenso wenn man aus Modellsicht gerne eine xor-Beziehung umsetzen will (hatte ich ja genannt, Person kann ein Lehrer xor Schüler sein). Rein technisch kann man so etwas über Trigger / Stored Procedures handhaben, so dass man eben ausschließt, dass solche Konstellationen auftreten können.

Hier sieht man aber, dass man eben viel mehr Infos in das Modell packen kann und dann bei der realen Umsetzung durchaus auf Schwierigkeiten stößt, über die man sich Gedanken machen muss.

[Reinhold]

Moin,

s

1.Normalisierung:

die Attribute dürfen nur atomar sein (ein Attributwert soll nicht aus 2 Werten bestehen:

falsch: | Strasse 12|

richtig: | Strasse | 12 |

ich wage zu bezweifeln, das die Hausnummer wirklich eine eigenständige Information ist und in der Praxis wird ME Strasse und Hausnummer quasi nie getrennt. In so fern finde ich das Beispiel fragwürdig...

2. Normalisierung

-wenn die 1.Normalisierung realisiert wurde und ein Nicht-Schlüsselattribut voll funktional abhängig von einem Schlüsselattribut ist

z.B.In der Tabelle Kunde ist das Attribut Telefonnummer voll funktional abhängig vom Primärschlüssel Kundennr und von keinem anderen Attribut.

Nach deinem Beispiel oben müsstest du dann aber auch die Telefonnummer in mehrere Informationen aufspalten (Landesvorwahl, Vorwahl, Rufnummer, Durchwahl , ...) Demzufolge wäre ja hier deine Tabelle nicht in der 1. NF

Reinhold, der sich seine Ohren redlich verdient hat

[dr.dimitri]

ich wage zu bezweifeln, das die Hausnummer wirklich eine eigenständige Information ist und in der Praxis wird ME Strasse und Hausnummer quasi nie getrennt.

Es gibt diverse Anbieter im Internet (z.B. 1&1) die die eingegebene Adresse validieren. Und dabei wird selbstverständlich die Strasse von der Hausnummer getrennt. Gleiches gilt auch wenn ein Drop Down Menü angegeben wird und man den Straßennamen auswählen kann.

Nach deinem Beispiel oben müsstest du dann aber auch die Telefonnummer in mehrere Informationen aufspalten

Ich hoffe nicht, dass das irgend jemand anders macht.

Dim

[Sarene]

Nach deinem Beispiel oben müsstest du dann aber auch die Telefonnummer in mehrere Informationen aufspalten (Landesvorwahl, Vorwahl, Rufnummer, Durchwahl , ...)

also ich weiß ja nicht. Irgendwie vergleichst du gerade Äpfel mit Birnen.

Wie ist die 1. Normalisierung denn sonst zu erklären?

EDIT: ich muss doch noch was dazu sagen :-)

Im Prinzip hast du Recht, aber wie viele das so umsetzen ist die andere Frage. Falsch wäre es, meiner Meinung nach, bestimmt nicht eine Telefonnummer in ihre Bestandteile aufzusplitten. Vielleicht ist das sinnvoll, wenn man unterschiedliche Ländervorwahlen hat zum Beispiel. Im Endeffekt ist es das gleiche wie mit PLZ und Ort: legt man für die Orte jetzt extra eine neue Tabelle an oder nicht? Ich glaube das liegt im Auge des Entwicklers :-)

Bearbeitet 21. April 2010 von Sarene

[kingofbrain]

Ich glaube das liegt im Auge des Entwicklers

Ich denke, das wird hauptsächlich von den fachlichen Anforderungen an eine Software festgelegt. Ich habe in vielen Anwendungen Adressdaten relativ unnormalisiert (Straße und Hausnummer ein Feld, mit PLZ und Ort in einem Tupel) verwendet. In meinem jetzigen Projekt (öffentliche Hand, Hierarchien von behördlichen Stellen mit Adress- und Kontaktinformationen) ist es eine wesentliche Forderung, die Adressdaten sehr fein granuliert zu verarbeiten. Genauso bei den Telefon- und Faxdaten. Die werden hier in jeweils vier Feldern verarbeitet.

Peter

[Sarene]

oder so, genau

[MartinSt]

ich wage zu bezweifeln, das die Hausnummer wirklich eine eigenständige Information ist und in der Praxis wird ME Strasse und Hausnummer quasi nie getrennt.

Das Datenmodell von ELSTER (elektronische Übertragung von Steuererklärungen) trennt z.B. in die 3 Bestandteile Straße, Hausnummer, Hausnummernzusatz.

[flashpixx]

Das Datenmodell von ELSTER (elektronische Übertragung von Steuererklärungen) trennt z.B. in die 3 Bestandteile Straße, Hausnummer, Hausnummernzusatz.

Gerade bei öffentlichen Verwaltungen und der dort eingesetzten Software sind solche Dinge manchmal sehr seltsam z.B. wird der Name (d.h. Nachname) auf max 120 Zeichen limitiert, es muss aber noch ein weiteres Feld mit max 60 Zeichen als Namensergänzung enthalten sein. Ein Feld mit 180 Zeichen darf nicht existieren bzw. man muss halt dann immer ein substr bei der Ausgabe des Feldes machen. Namen die 180 Zeichen überschreiten werden einfach abgeschnitten. (hatte damit einige Jahre zu tun, gerade in diesem Bereich knallt die rationale IT gegen die Bürokratie)

[Reinhold]

moin,

Das Datenmodell von ELSTER (elektronische Übertragung von Steuererklärungen) trennt z.B. in die 3 Bestandteile Straße, Hausnummer, Hausnummernzusatz.

jetzt wo du das sagst fällt mir ein, ich hatte vor Jahren mal mit einer Software für Ver- und Entsorger zu tun, da gab es zu diesen 3 Teilen zusätzlich noch Hausnummererweiterung und Hausnummerergänzung...

Also falls deren Abnahmestelle an der Adresse "Unter den Eichen 14b, Hinterhof, 2.OG, links" war, war diese Software perfekt dafür ausgestattet.

Also ich glaube, wir hier bei unseren Datenbanken lassen das auch in Zukunft in einer Spalte, aber das mag jeder halten wie er will.

Off Topic (oder auch nicht): Ich plage mich gelegentlich mit einem IMHO extrem übernormalisierten Modell herum. Dort wurden z.B. Person und Geschlecht ganz korrekt mit der Verbindungstabelle Personengeschlecht als n:m-Beziehung abgebildet. Leider habe ich nun Personen vorgefunden, die gleichzeitig männlich, weiblich und undefiniert sind... Sachen gibts...

Reinhold

BTW: Ich wollte hier keinen Glaubenskrieg lostreten.

[MartinSt]

Solche detaillierten Adressangaben können ja u.U. auch sinnvoll sein, etwa für Rettungsdienste o.ä. - entscheidend ist immer was man mit den Daten machen will.

Evtl. plant ja bei ELSTER das BMF auch eine Steuer für Hinterhausbewohner. :eek

Leider habe ich nun Personen vorgefunden, die gleichzeitig männlich, weiblich und undefiniert sind... Sachen gibts...

Evtl. war ja das eine fachliche Historisierung.

[Carnie]

Inzwischen macht das sogar Sinn...zumindest in Australien

Norrie first registered sexless person

[net-tobi]

Hallo Jungs

also erstmal danke für das rege Intresse an diesen Thema schätze habe da eine heiße Diskussion entfacht.

Was ich bis jetzt so rausgelesen und auch nachgegooglet habe ist echt intressant.

Wenn ich das also teilweise aus den Aussagen richtig verstanden habe bedeute dies, der Entwickler ist im Endeffekt an nichts streng gebunden. Ausser es gibt konkrette Vorgaben.

Was ich mich aber gerade die Frage bringt, gibt es eigentlich sowas wie einen Datenbank Knigge? Also gibt es Sachen an die man sich halten sollte?

Denn in der Datenbank die ich hier mit verwalte sind Daten stellenweise doppelt geschrieben. Ebenso ist nicht immer gleich der Zusammenhang zwischen den Tabellen einfach zu begreifen. Denn hier hat der Entwickler die Daten in der Tabelle umgeschlüsselt.

Beispiel

Tabelle 1 Spalte Art

Tabelle 2 Spalte ID Spalte Test

Erklärung zu den Beispiel: Wenn man in Tabelle 1 schaut steht dort die Spalte Art dies kann man dann in Tabelle 2 verfolgen auf Spalte ID und diese dann auf Spalte Test.

Es gibt aber keine Beziehung zwischen den Tabellen oder gar Primär / Fremdschlüsseln in den Tabellen.

Wie ihr euch vorstellen könnt ist es so sehr sehr schwer sich hier einzuarbeiten.

Darum die Frage ob es sowas wie einen Datenbank Knigge gibt.

Sorry ein bessere umschreibung eingefallen.

Schönen Sonntag und eine ruhige Woche

net-tobi

[flashpixx]

Wenn ich das also teilweise aus den Aussagen richtig verstanden habe bedeute dies, der Entwickler ist im Endeffekt an nichts streng gebunden. Ausser es gibt konkrette Vorgaben.

Naja ERM/ERD und Normalisierung sind gängige Methoden, an die Du Dich halten solltest.

Es gibt aber keine Beziehung zwischen den Tabellen oder gar Primär / Fremdschlüsseln in den Tabellen.

Also Datenbank ohne Schlüssel (hatte ich aber auch schon in den Händen) darf/sollte nicht sein.

Ich muss sagen, dass ich bei größeren Datenbankprojekten das ERM überlege, dann das ERD erstelle, hierzu nehme ich aber direkt die UML Notation und nicht Chen-Notation und aus dem Diagramm normalisiere ich bis in die BCNF, wobei ich das _sinnvoll_ mache, denn je nach technischer Anforderung des DBMS muss man eben im Hinblick auf das Design eben Änderungen mittragen. Ich denke der "Datenbank-Knigge" ist eben ERM/ERD und Normalisierung. Wichtig in meinem Design ist eben keine Redundanzen zu erzeugen, eine strukturierte Datenhaltung, d.h. auch passende Benennungen der Tabellen, Felder usw., so dass man eben schon durch die Benennung auf den Inhalt schließen kann und ich versuche eben so weit es möglich ist, innerhalb der Datenbank alle Verarbeitung durchzuführen, d.h. nach außen ist die Datenbank für mich atomar, d.h. zu jedem Zeitpunkt enthält sie einen definierten Stand der Daten

[Guybrush Threepwood]

Ich hoffe nicht, dass das irgend jemand anders macht.

Natürlich, jeder der es nicht getrennt braucht. Dinge die sich in der Theorie gut anhören sind es nicht unbedingt auch in der praxis, das heißt man sollte einen guten Mittelweg finden wie weit man bestimmte Dinge normalisiert.

PS: Auch Redundanzen können in bestimmten Fällen besser sein als diese auf Teufel komm raus zu vermeiden.

[Goos]

Was ich mich aber gerade die Frage bringt, gibt es eigentlich sowas wie einen Datenbank Knigge? Also gibt es Sachen an die man sich halten sollte?

Sowas gibt es so direkt nicht. Wer sich allerdings etwas intensiver mit der relationalen Theorie beschäftigt, wird früher oder später Werke von C.J. Date, oder auch Fabian Pascal lesen.

Was man aus alledem dann praktisch macht ist in meinen Augen doch eher Erfahrungssache. Prinzipiell sollte man aber die Theorien kennen um zumindest genau zu wissen, weshalb man etwas so oder auch anders macht.

Goos