Datenbanken erstellen - Grundsätzliches - Hilfestellung erbeten

[msteffenma]

Hallo,

nach langen Jahren Excel-Wirkens möchte ich viele Dinge mit Datenbanken lösen. Bin zwar sehr fit in Excel und werde vieles weiterhin mit Excel machen, aber ich habe mich von einem Freund überzeugen lassen, dass vieles mit einer DB besser zu lösen ist. Denn alles was in Excel nur mit viel Aufwand (VBA, Matrixfunktionen etc.) zu machen ist, sollte mit einer DB besser zu erstellen sein. Leider hat er momentan nicht die Zeit, mich hier einzuleiten.

Nun gut. Ich habe fundierte Grundkenntnisse durch Access im Geschäft. Also Felder, Datentypen usw. Sind nicht das Problem. Aber Access gibt es ja nicht für MAC und Filemaker (wäre mein Favorit gewesen) ist mir privat einfach viel zu teuer.

Nun habe ich mir Navicat für Sqlite gekauft und möchte nun mit SQL (Sqlite) loslegen. Gerade auch, da Sqlite ja auch bei der Programmierung zur Datenablage anscheinend oft genutzt wird (MAC OS, IOS). Und hier habe ich gerade angefangen, mich auf XCODE einzulassen. Entwickelt habe ich bisher auf Windows mit C# und hauptsächlich mit VBA Excel. Netzwerkfähigkeit, Rechtevergabe und Multiuser brauche ich nicht. Mir geht es rein um die Ablage von Daten. Sqlite langt hier bestimmt. Habe viel gutes gelesen über diese kleine DB.

So... was ich bräuchte, ist einfach der richtige Start. Wie bereitet man Datenbanken für SQL vor. Normalisierung ist ja hier ein großes Thema. Wie benenne ich Datenfelder richtig, wie bereite ich die Datenbanken vor, um sie miteinander zu verbinden. Was sind die gröbsten Fehler, die ich hier machen kann bei der Entwerfung von Datenbanken. Wie bekomme ich die Daten dann performant angezeigt? Extra Tool? Export zu Excel? Ich rede natürlich nur von MAC Lösungen.

Ich weiß, etwas viele Fragen. Aber ich möchte hier gerne den Erfahrungsschatz anderer als Hilfestellung nutzen.

Danke und Grüße

Martin S.

 

[ImperatoR]

Also grundsätzlich sollte sogar das Terminal genügen und für sqlite gibt es für alle möglichen Programmiersprachen Kommnunikationsmöglichkeiten. Ich weiß jetzt nicht, was dein Anspruch ist, somit kann ich dir auch keine Empfehlungen was Programmiersprachen/Workflow betrifft.

Zum Thema SQL: Damit du keinen Stress hast, ist ein sorgfältig geplantes Schema sehr wichtig. Also solltest du dir erst einmal ein Entity-Relationship-Modell malen, dort siehst du relativ schnell und übersichtlich was noch verbesserungswürdig ist. Dies gilt es dann in ein logisches Modell (z.B. eine Tabelle) umzusetzen und vor allem redundante Informationen geschickt umgehen und auslagern (nicht nervt mehr als das). Zudem sollten saubere Constraints definiert werden, damit das DBMS schon die Korrektheit der Daten überprüfen kann. Und dann das alles ins SQL übersetzen, was dann aber nicht mehr allzu schwer sein sollte.

 

[msteffenma]

Hallo, Imperator,

Erstmal Danke für dein Feedback.

OK. Terminal würde langen. Bloß habe ich in 3 Jahren MAC OS vielleicht 10 Minuten im Terminal verbracht. Das wollte ich schon ewig mir mal antun. Aber das wäre wieder eine Baustelle mehr.

Ich will Daten eingeben, verwalten und ausgeben. Vorerst noch nicht programmieren. Dafür braucht es halt ein Front-End. Deine kurze und pragmatische Anleitung ist für einen DB Experten bestimmt schlüssig. Aber ich weiß noch nicht mal, was ein Entity-Relationship-Modell ist. Mir geht es um die Basis. Etwas leichter verständlich erklärt. Gerne auch einen Link für Recherche.

Na ja, ich werde mich halt den ganzen Abend durch die "Google Welt" quälen.

Ciao

 

[ImperatoR]

Also ich selbst finde relationale Datenbanken nicht sonderlich berauschend. Meine Gilden-Homepage habe ich daher mit (dokumentenbasierte) CouchDB geschrieben, aber ich sage gleich vorweg, dass man dort ersteinmal sich in diese Struktur einarbeiten muss (aber es gibt ein sehr gutes und kostenfreies Online-Buch dazu).

Daher denke ich dein Ansatz mit dem recht einfachen sqlite ist vernünftig. Aber du schreibst davon, dass du Daten eingeben, verwalten und ausgeben willst, jedoch es sei gesagt dass relationale Datenbanken (wie auch sqlite) sich für ändernde Strukturen nur schlecht eignen! Hast du ein festes Schema definiert (das o.g. ER-Diagramm), welches sich idealerweise nicht mehr ändert oder nur in einem geringen Umfang, sind rel. Datenbanken echt super.

Wenn du wechselnde Strukturen hast, könnte es sich sogar lohnen in eine dokumentenbasierte Datenbank einzuarbeiten. Wenn es aber um mehr oder weniger Dokumentenhaltung geht ist wohl DevonThink oder Evernote (oder vergleichbar) zu empfehlen. Und je nach Umfang der Daten mit Multimarkdown, oder vergleichbar einfachen Formaten zu arbeiten. Oder XML?

 

[msteffenma]

Daher denke ich dein Ansatz mit dem recht einfachen sqlite ist vernünftig. Aber du schreibst davon, dass du Daten eingeben, verwalten und ausgeben willst, jedoch es sei gesagt dass relationale Datenbanken (wie auch sqlite) sich für ändernde Strukturen nur schlecht eignen!

Das Projekt, das ich vorhabe, hat keine veränderlichen Strukturen. Einmal erstellt, geht es nur noch um täglich neue Daten einzugeben. Es wird am Aufbau der DB nichts mehr geändert.

Ich möchte eine Datenbank erstellen, in der Auftragsdaten eingegeben werden können. Zu den Aufträgen gibt es verschiedene Mandanten (Kunden, Auftaggeber), Mitarbeiter, Artikel und, und ,und. Da entstehen sofort 10-20 Tabellen. Verliere hier einfach den Überblick, wie ich das alles zusammen "wurschteln" muss.

Vorher habe ich solche Dinge immer mit Excel erledigt. Aber eine Datenbank wie schon im Erstposting geschrieben passt hier einfach besser. Jetzt fängt es halt an. Wie erstellt man Relationen richtig. Wie benennt man Datenfelder am besten usw. Wo fange ich an beim erstellen dieser Datenbank(en). Papierform?

Ich will es gar nicht so sehr technisch haben. Eher als Anleitung, wie generell hier vor zu gehen ist.

Aber vielen Dank für deine Hilfestellung.

 

[jp10686]

Ich habe beruflich mit DB-Entwicklung zu tun und kann Dir nur raten, nochmal FileMaker in Erwägung zu ziehen. Der Preis schmerzt nur einmal, aber gerade bezüglich Dateneingabe ist das Programm unschlagbar, und Daten eingeben ist bei Auftragsverwaltungen usw. das sowieso zeitintensivste und fehleranfälligste, was es in der Arbeit damit zu tun gibt. Wie man selber, geschweige denn andere Personen, Daten fehlerfrei in viele Tabellen eingeben und korrekt verknüpfen kann (du sprichst von 10 - 20 ), ohne eine Oberfläche mit Formularcharakter und Eingabeüberprüfung, kann ich mir schlicht nicht vorstellen. Sind die falschen Daten erstmal drin, findet man sie kaum je wieder, wenn die Datenmenge gross ist. Überprüfungsroutinen sind also essentiell.
Zum Verwursten von grossen Datenmengen (z.B. Suchabfragen über Verknüpfung mehrere Tabellen mit je einigen 10'000 Datensätzen) ist FileMaker nicht optimal (langsam), aber man kann die Daten jederzeit exportieren und mit einem schnelleren Programm verarbeiten, oder FMPro auch nur als Eingabehilfe für ein sql-basiertes System verwenden.
Was die Fragen zum Design, zur Feldbenennung usw. betrifft, so würde ich mir erst mal ein allgemeines Werk darüber zu Gemüte führen; die Konzepte sind bei allen Applikationen gleich. Allgemein deshalb, weil gerade Bücher über Kleinweich-Programme dazu neigen, die programmspezifischen Bezeichnungen zu verallgemeinern (so wie dort prinzipiell kaum je zwischen "Windows" und "Betriebssystem" unterschieden wird), was spätestens dann für Verwirrung sorgt, wenn man sich später in das ausgewählte Programm einarbeiten will.
Und dann besteht die Kunst des DB-Designs vor allem darin, an alles zu denken - darf es mehr als einen Jochen Schmidt geben? Könnte der Kunde Lieferungen an verschiedene Adressen wollen? Gibt es mehrere Ansprechpersonen in der gleichen Firma, die unterschieden werden sollen? Ist Liefer- und Rechnungsadresse immer identisch? Braucht man einen Verlauf, d.h. soll ersichtlich sein, wann was wohin geliefert und von wem wie wann bezahlt wurde? Falls ja, müssen dynamische Links wie Kunde <-> Adresse statisch abgelegt werden, weil, wenn der Kunde inzwischen den Wohnort gewechselt hat, sonst alle Lieferungen als an den gerade aktuellen Wohnort erfolgt angezeigt werden. Und so weiter.
Falls Du für Dritte entwickelst, ist es hilfreich, wenn diese Personen wissen, was sie eigentlich genau wollen.

 

[Kojak19]

Bevor es ans Erstellen am Rechner geht, nimm dir ein großes Blatt Papier.
Dort machst du dir für jedes Argument dass du benötigst, z. B. Name, Adresse, Firma etc., einen Kasten.

Und nun kommt, wie jp10686 schon geschrieben hat, die große Kunst an der Geschichte.
Du musst dir genau überlegen, in welcher Beziehung die einzelnen Argumente zueinander stehen "könnten".

Beispiel: Zu einem Namen können mehrere Adressen, Firmen und so weiter gehören.

Diese Verbindungen musst du in deiner Datenbank realisieren.
Diese Vorarbeit wird als Entity-Relationship-Model bezeichnet.

Hier mal ein Beispiel: klick
Und der dazugehörige Wiki-Eintrag: klick

 

[ImperatoR]

Habe ich was anderes behauptet?

 

[msteffenma]

Vielen dank an Alle hier. Das mit dem FM ist so eine Sache. 400 EUR sind ein Haufen Geld und der Geschäftsführer unserer Firma zahlt die nicht. Hatte die Demoversion von FM 11 auf meinem MAC und war sehr angetan. Aber für mich privat zum autodidaktischem Lernen so viel Geld ausgeben...

Ich werde mal schauen, wie ich hier ran gehe. Was ich jetzt auf jeden Fall machen werde, ist alles vorab auf dem Blatt Papier vorab zu erstellen. Schlagwort Entity-Relationship-Model. Das ist ja auch bei Exceltabellen nützlich. Kannte ich so noch nicht.

Gruß

Martin S.

 

[ImperatoR]

Hast ja das Skript.