Entwicklung eines Datenbanksystems

Säsch

Aktiver Benutzer
Beiträge
40
Hallo IT-Community,

ich hoffe ich bin in diesem Forenteil richtig. Mir geht es nämlich darum Basiswissen zu schaffen. Ich weiß im Moment nicht wo ich am Besten anfangen soll.

Ich fange in genau einem Monat meine Bachelorarbeit an und habe 84 Tage Zeit ein Datenbankenkonzept zu entwickeln.

Die Ausgangssituation ist folgende: In meiner Firma wird zur Zeit der komplexe Prozess der Aufwandsabschätzung von Produktentwicklungen mit Hilfe von Excel-Blättern gemacht. Diese laden auf Grund Dateigröße und Netzwerkanbindung teilweise sehr langsam. Daten müssen mehrmals eingegeben werden. Das ganze ist wegen hohem Grad an manuellen Abreitsschritten ungeeignet für diesen Prozess (Fehleranfälligkeit, lange Dauer). Am Ende des Prozesses sind dann alle Daten in diesem Excel-Sheet und für alle End-User unbequem zu erreichen. Wenn zum Beispiel ein Direktor folgende Frage stellt: "Wie hoch sind die prognostizierten Entwicklungskosten für die nächsten 2 Quartale?", müssen zunächst alle Excel-Dokumente gesucht werden und manuell zusammengefügt werden (Fehleranfällig, lange Dauer). Das fertige Dokument wird dann von Sales übernommen, die damit den Business Case und das Angebot definieren. so viel zu den Basics...

Nun will die Firma von mir ein Datenbank-Konzept, dass das alles regeln kann. Natürlich habe ich das Thema angenommen. Die Firma gefällt mir, das Thema ist technisch (bin wirtschaftsingenieure und war auf der Suche nach einer technischen Abschlussarbeit) und ich habe bereits eine Datenbankenvorlesung besucht.

Das problem ist nun foglendes: Ich hab die Vorlesung besucht und 3 Bücher geliehen/gekauft: Andreas Meier (Rel. und postrel. DBs), S. Kleuker (Grundkurs DB-Entwicklung) und der dicke Wälzer C.J. Date (An Intro to DB-Systems). Alles eben genannte hat nur Datenbanken-Modellierung zum Thema: ER-Diagramme, SQL, ... eben die Theorie, ... praxisfern.

Wie bekomme ich am besten raus welche Client-Server-Lösung für mein Problem am besten geeignet ist - kann mir jemand Literatur empfehlen, die mir erklärt was es für Möglichkeiten gibt und welche Software für mich am Besten geeignet ist (Front-End / Back-End)? Ich habe mir zum Beispiel gedacht, dass man eine Excel-Oberfläche als Front-End entwickeln könnte, die alles in eine Datenbank lädt: Dann hätte man den Vorteil der steilen Lernkurve von Excel-Dokumenten und Kostengünstigkeit, denn Excel-Linzenzen sind genug vorhanden.

Kann mir jemand Software empfehlen, die ich als "Spielwiese" zum Üben nutzen kann? Habe nur MS Access. Wie kann ich am günstigsten einen Prototyp entwickeln?

Durch Querlesen im Netz und anderen Quellen, bin ich an ein wenig Praxis-Info gekommen. Liege ich damit richtig? =>

-Es gibt grundsätzliche 2 Möglichkeiten eine C-S-Architektur einzurichten: Entweder über das Netzwerk mit TCP/IP Schnittstelle oder über das Internet mit PHP.

-Es gibt 2 Möglichkeiten einen Server einzurichten: Entweder über eine Online-Cloud oder geeignete Hardware. Eine Cloud-Lösung ist von der Firmenleitung nicht erlaubt.


Sorry für den vielen Text. Ich hoffe ihr könnt mich mit ein paar Infos versorgen, sodass ich meine Basis irgendwie aufbauen kann.

Viele Grüße
 
Werbung:
So wie ich das verstehe hat er ja schon Bücher und Wissen zur Datenbank und zum Aufbau relationaler Daten. Für das Frontend fehlt dir entweder eine Programmiersprache, hier wirst du aber in 84 Tagen keine Eigenentwicklung einer Anwendung hinbekommen, oder eine "einfache" Frontend Variante mit Excel oder einer anderen Software.

Interessieren würde mich das auch, gearbeitet habe ich aber bisher nur mit Abfragen aus Excel heraus, keine Schreibvorgänge.
 
Lustig wird es spätestens dann wenn die User VBA-Code abschalten... da Sie ein "Sicherheitsrisiko" sehen... Erklär denen dann mal dass Sie dann keinen Zugriff auf die Datenbank haben :)

Wenn man den Usern ein paar Daten zur Verfgügung stellen will ja, aber alles was darüber hinaus geht braucht mMn eine restriktivere Umgebung.
 
Ich fange in genau einem Monat meine Bachelorarbeit an und habe 84 Tage Zeit ein Datenbankenkonzept zu entwickeln.

Soll bei bei einem reinen DB-Konzept bleiben, oder soll eine fertige Applikation bei rausfallen? Das eine halte ich für durchaus realistisch, das andere nicht.
Gibt es Vorgaben, Restriktionen? Zum Beispiel bestimmte OS-Umgebung, Lizenzen?

Wenn Du eine Spielwiese für eine ausgereifte SQL-Datenbank haben willst, kannst Du PostgreSQL nehmen. Das ist leistungstechnisch in einer Liga wie Oracle - und völlig frei verfügbar, auch für kommerzielle Produkte.

Um eine komplette Applikation zu machen brauchst Du aber auch etwas für den Endbenutzer. Das ist erheblich mehr Arbeit.
 
Wenn ich das so lese, würde ich Dir den Tipp geben, Dich rein auf das Datenbankkonzept zu beschränken. Bei dem Basiswissen, das Du durchscheinen lässt, würde die technische Umsetzung schon einen Großteil der Zeit ausmachen. Vertue Deine Zeit damit nicht. Dafür soll die Firma sich einen Informatiker nehmen.
Wenn Deine Aufgabenstellung wirklich nur darin besteht, ein DB-Konzept zu erstellen, dann könntest Du es in jeder SQL basierten DB umsetzen. Für jede gibt es entsprechende Tools, mit denen man sich das komfortabel zusammenklicken kann. Dauern würde es wahrscheinlich trotzdem die vollen drei Monate.
Wenn ernsthaft auch eine technische Umsetzung von Dir erwartet wird, oder Du sie dann auch zeitnah für die Firma umsetzen willst, dann solltest Du Dir tatsächlich Access angucken. Ich habe damit zwar keine Arbeitserfahrung, die aus diesem Jahrhundert stammt, aber inzwischen scheint Access durchaus auch einige SQL-Konzepte zu beherrschen - zumindest so viele, dass es für Deine Aufgabenstellung ausreicht -, Access kann rudimentär mit Transaktionen umgehen, auf einem lokalen Server laufen und vermutlich wirst Du keine Datenbank finden, die sich leichter an Excel anbinden lässt. Access scheint mir nach allem, was Du schreibst, die einzige Möglichkeit für Dich, das so in dem Rahmen zu schaffen.
Ginge es nur um das DB-Konzept, wäre auch PostgreSQL eine Option. Aber dafür das bei deinem Wissensstand in PostgreSQL zu realisieren, inkl. der Anbindung an Excel, der Installation eines lokalen Servers etc. ist die Zeit viel zu knapp. Zudem scheint mir, dass in der Firma nicht das Know-how vorhanden ist, um einen Linux-Server mit PostgreSQL zu pflegen und zu warten.

Deshalb mein Tipp: Installier Dir Access, recherchiere, ob es grafische Tools für die Entwicklung gibt. Lies Dich intensiv in Normalformen, Fremdschlüssel, Surrogate Keys etc. ein, guck Dir andere Datenbank-Realisierungen an, finde Namenskonventionen für DB-Tabellen und -Spalten, damit Du nicht eine Woche vor Abgabe 50 Spaltennamen ändern musst. Arbeite Dich intensiv in SQL ein und spiele mit den Daten aus den Excel-Sheets herum. Eine DB-Vorlesung macht noch keine Praxis, deshalb wirst Du viele Tabellen wieder löschen, umbennen, mit anderen zusammenlegen oder aufspalten und nicht von vorne herein ein fertiges Design erstellen.
Als letzter Tipp: Alles braucht immer viel länger als man denkt. Deshalb beschränk Dich so gut es geht und mach nur genau das, was Du vorgegeben bekommen hast.
 
Dem Unternehmen ist ein Konzept wichtig! Am Ende geht das ganze wohl eh an einen IT-Spezialisten. Es soll ein Konzept sein, dass zeigt, wie man alles verbinden könnte und strukturieren. Produktinformationen liegen beispielsweise in einem komplexen System das Windchill heißt, Kundeninformationen in der Sales-Datenbank. Es ist alles irgendwo schon vorhanden, jedoch verstreut. Mein Konzept soll alles verbinden! Man kann in der Datenbank ja auf andere Datenbanken referenzieren.

Der Professor allerdings möchte gerne einen Prototypen sehen. Das kann auch etwas einfaches sein. Es soll nur gezeigt werden, dass meine Idee funktioniert.

Das Thema "Vorgaben" ist als Praktikant sehr schwer zu lösen. Die Firma hat ca. 2000 Mitarbeiter und es werden unzählige Programme genutzt. Mein chef meinte, dass ist Teil meiner Arbeit, die beste Lösung zu finden. Schwierig. Weiß noch nicht mit wem ich sprechen muss.

Und zum Thema "Endbenutzter" soll ich auch analysieren, wer überhaupt alles als Endnutzer in Frage kommt. Für die Finanzabteilung reicht es beispielsweise, wenn alle geschätzten Zeiten und Kosten einfach in eine Datenbank kommen. Die suchen sich das Zeug selbst raus mit ihren Tools. Das Sales-Team hingegen möchte alle Kosten, Zeiten und Produktinformationen zugeordnet zu Geschäftsszenarien. Eben alles, was für eine Angebotsdefinition notwendig ist.
Der Fordergrund im Thema "Endbenutzer" steht also Controlling und Angebotsdefinition.

Viele Grüße
 
Das Thema "Vorgaben" ist als Praktikant sehr schwer zu lösen. Die Firma hat ca. 2000 Mitarbeiter und es werden unzählige Programme genutzt. Mein chef meinte, dass ist Teil meiner Arbeit, die beste Lösung zu finden. Schwierig. Weiß noch nicht mit wem ich sprechen muss.

Und zum Thema "Endbenutzter" soll ich auch analysieren, wer überhaupt alles als Endnutzer in Frage kommt. Für die Finanzabteilung reicht es beispielsweise, wenn alle geschätzten Zeiten und Kosten einfach in eine Datenbank kommen. Die suchen sich das Zeug selbst raus mit ihren Tools. Das Sales-Team hingegen möchte alle Kosten, Zeiten und Produktinformationen zugeordnet zu Geschäftsszenarien.

Das klingt nach vielen gleichzeitigen Usern, die auch noch unterschiedliche Rechte haben. Und das klingt nach einer Server-Lösung. Also für mich klingt es nach PostgreSQL ;-) Für die Endbenutzer kann das dann eine Webanwendung sein, oder aber mit irgend was anderen, PG spricht alle möglichen Protokolle. Und zur Einbindung bereits bestehender Daten gibt es FDW (Foreign Data Wrapper). Ja, ich geb zu, das ist eine steile Lernkurve.
 
Genau! Viele unterschiedliche Nutzer mit anderen Rollen und unterschiedlichen Rechten! Es handelt sich um ein funktional organisiertes Unternehmen mit verschiedenen Abteilungen wie Finance, Controlling, HR, Sales, Tests, Development.
 
Ok, vergiss meine Antwort. Das ist ja wieder eine ganz andere Aufgabenstellung und Größenordnung. Für so etwas käme dann nur ein ausgewachsenes DBMS in Frage, wenn nicht sogar ein Data-Warehouse-System.
Wenn Du es als DBMS realisierst, beispielsweise in PostgreSQL, dann würde ich es, aus dem Ärmel geschüttelt, wie folgt realisieren: Die meisten vorhandenen Datenbanken (z. B. Windchill) laufen weiter und Du holst Dir die Daten über Schnittstellen und gibst sie als (materialized) Views an die Anwendungsdaten weiter. Der Unterschied zu einem DW-System besteht darin, dass die Daten weiterhin in der spezialisierten DB liegen und von Deiner DB nur gespiegelt werden. Dort wo es Sinn macht, kannst Du natürlich auch kleinere Datenbanken in deiner zusammenführen.
 
Genau! Viele unterschiedliche Nutzer mit anderen Rollen und unterschiedlichen Rechten! Es handelt sich um ein funktional organisiertes Unternehmen mit verschiedenen Abteilungen wie Finance, Controlling, HR, Sales, Tests, Development

Ich hab mal eine Vortrag von Jan Mussler gesehen, der arbeitet bei/für Zalando. Die machen ALLES in PostgreSQL, haben sich dafür sogar eine eigene API geschrieben. Das ist richtig cool. Du findest dazu mehr via Google "jan mussler elephanten sind in mode". Das zeigt zumindest, was so möglich ist.
 
Also an den laufenden Datenbanken darf ich eh nichts ändern und wird auch nichts geändert. Windchill wurde zum Beispiel gerade vor kurzem erst gekauft. Es geht nur um eine Datenbank für den Aufwandsabschätzung-Prozess. In dieser soll ich aus laufenden Datenbanken eben die Dinge ziehen, die benötigt werden. Bei den Produktinformationen, die mit der Aufwandsabschätzung zusammenhängen, handelt es sich beispielsweise auch um hochkomplexe CAD-Zeichnungen, die sowieso nur in Windchill liegen können!
 
Dann sind Views wohl genau die Lösung. Damit reduziert sich Deine Aufgabe auf die Anbindung der unterschiedlichen Datenbanken und die Erstellung der Views. Das klingt mir deutlich schaffbarer.
Da mit Views die eigentliche Logik in die Datenbank verlagert ist, kannst Du ein beliebiges Front-End nehmen, was die Datenbank ansprechen kann (Excel, fertige PHP-Skritpte, ...). Als Back-End kämen die großen DBMS in Frage, also Oracle, DB2, MSSQL oder PostgreSQL. Hier musst Du prüfen, welche Schnittstellen die vorhandenen Datenbanken haben und welche DBMS darauf zugreifen können. Wenn es von den Schnittstellen her geht, ist PostgreSQL eine gute Wahl, wenn die Firma das Geld locker machen will, ist Oracle eine bessere. Aber trage erst mal die Datenbanken und die vorhandenen Schnittstellen zusammen und entscheide Dich dann für ein DBMS.
 
Werbung:
Ich glaube Oracle is schon vorhanden. Das weiß ich noch nicht.
Also Hauptkriterium beim Software-Vergleich wären ja dann zunächst einmal die Schnittstellen.

Ich habe morgen ein Meeting mit einem IT-Fachmann des Unternehmens organisiert. Habt ihr irgendwelche wegweisenden Fragen, die ich ihm stellen könnte? Nun folgt eine grobe Auflistung an Dingen, die mir einfallen:

-Was nutzt ihr für Back-End-Software? Oracle? Wenn ja wäre doch das am besten geeignet? Wegen größter Anzahl an Schnittstellen?
-Welche Back-End-Software hat alle nötigen Schnittstellen für alle zusammenhängenden Datenbanken? Bzw. was sind alle zusammenhängenden Datenbanken und was sind ihre Schnittstellen?
-Was für ein Front-End wäre erwünscht? Eines über Browser (PHP) oder nicht über den Broswer (z.B. Excel, sonstiges)?
-Ist eine "View-Regelung" in meinem Datenbanken-Konzept möglich?
-PostgreSQL?
 
Zurück
Oben