Aufbau einer Datenbankeingabemaske

S

stud3

Aktives Mitglied
hallo ,
von den Punkten, die ich hier zitiere was mich besonders interessieren würde ist, welche Details sollten die Funktionen Hinzufügen, Löschen, Ändern und Suchen abdecken, . Da könnte ich z.B. den Fall nennen, wenn der Benutzer mehrmals dieselben Einträge beim Hinzufügen eingibt, was Redundanzen in der Datenbank erzeugt, oder der Fall wenn er falsche Werte eingibt, z.B. xxxxx für Name (da ich darüber schreibe, das ist auch eine von vielen Fragen), wie würdet ihr diesen Fall abfangen?, solche Sachen unter anderen sind was mich interessiert, zu wissen.
Ich brauche keine Codes, ich brauche Tips über eine gute Vorgehensweise bei dem Aufbau einer DBEM, ob ich auch z.B. Stored Procedures brauchen werde oder nicht, was sollte ich nicht vergessen bei dem Aufbau?
...und wenn jemand schon eine ähnliche Erfahrung hatte, würde ich mich sehr freuen eine Antwort von ihm/ihr zu bekommen... Gruß.

Aufbau einer Datenbankeingabemaske oder Datenbankapplikation

Anforderungen: Diese Eingabemaske sollte den Benutzern ermöglichen, manuell und beim Auswählen, Datensätze in eine Datenbank löschen, hinzufügen und ändern. Optional sollte es auch ermöglichen, Datensätze zu suchen. Meine Chefs haben mir angefordert alles nur für ein Template aufzubauen, d.h. für eine Tabelle, nach Möglichkeit (zeitlich) für 2 Tabellen.
Meine Schritte oder Pläne sind bisher die folgenden, es können noch andere kommen:
1. Startseite: diese beinhaltet das Login, derjenige, der berechtigt ist, diese DBEM zu nutzen, darf beim Klicken auf OK auf die nächste Seite der DBEM.
2. Die zweite Seite der DBEM beinhaltet die Sicht der entsprechender Tabelle mit ihren Spalten und Zeilen und die Werte drin. Die Tabelle oder die Sicht der Tabelle ist scrollbar auf der rechten Seite und unten, falls die Tabelle groß in Datensätzen oder Spalten ist.Außerdem muß dem Benutzer ermöglichen, einen Datensatz auszuwählen.
2.1 In dem Fall dass die Tabelle groß in Datensätzen wäre, würde unten so was wie ein Paging stehen, das dem Benutzer möglich macht, die Tabelle durchzublättern.
2.2 Unten von dem Paging würden die Buttons: Hinzufügen, Löschen, Ändern und Aktualisieren stehen.
3. Beim Klicken auf Hinzufügen, würde ein POP UP kommen, da stehen in Form eines Formulars, die Felder der Tabelle, d.h. Labels für die Bezeichnungen der Spalten der Tabelle, und Textfelder für die Eingabe der Werte entsprechend dieser Spalten.
3.1 Unten würden einfach die Buttons OK und ABBRECHEN stehen.
3.2 Beim Klicken auf OK, geht man zurück zu der zweiten Seite, man klickt auf Aktualisieren, und unten von der Buttonsleiste sieht man die Zeile, die man hinzugefügt hat. (Hier habe ich an vielenOptionen gedacht, vielleicht einfach direkt in der Tabelle sehen ob der neuer Datensatz da ist, aber was passiert wenn es um 100 Datensätzen geht?)
3.3 Funktionen zum Abfangen von Fehler beim Hinzufügen sind zu implementieren.
4. Bevor der Benutzer auf Löschen klickt, muß er einen Datensatz der Tabelle auswählen und dann auf Löschen klicken, dieses erzeugt ein POP UP oder einfach eine Meldung in JavaScript, mit Buttons OK und ABBRECHEN.
4.1 Beim Klicken auf OK passiert das gleiche wie auf Punkt 3.2.
4.2 Bevor der Benutzer auf Ändern klickt, muß er einen Datensatz der Tabelle auswählen und dann auf Ändern klicken, dieses erzeugt ein POP UP so formularmäßig, mit der Möglichkeit, den ausgewählten datensatz anzuzeigen und zu ersetzen durch einen anderen Datensatz, Buttons OK und ABBRECHEN sind dabei.

Ich habe viele Ideen, die ich hier nicht mehr geschrieben habe
Ich hoffe auch dieses Mal deutlicher geschrieben zu haben für diejenigen, die bei meinem Beitrag helfen wollen.

 
Diese Funktionen sollten grundsätzlich so arbeiten, wie es wohl die Mehrheit der Benutzer gewohnt ist. Beispielsweise sollte vor dem Löschen noch eine Sicherheitsabfrage ("wollen Sie wirklich?") erfolgen.

Bei jedem Speichern von Daten (also Hinzufügen und Ändern) sollten die Eingaben auf den korrekten Datentyp validiert werden (Bsp. Zahlen, Datumswerte). Dann kommen noch spezifische Validierungen, die von der Bedeutung des jeweiligen Feldes abhängen. So kann etwa ein Geburtsdatum nicht neuer sein als ca. 18 Jahre (sofern es nur erwachsene Benutzer sind). Einen Text kannst Du höchstens auf führende/folgende Leerzeichen und die Länge prüfen. Wenn einer beim Namen "xxxxx" eingibt, lässt sich das nicht wirklich abfangen, ausser Du prüfst ob alle Zeichen des Strings gleich sind. Aber dann kann einer immer noch "xxxxy" eingeben, also versuchs gar nicht erst ;-)
Redundanzen würde ich nach Möglichkeit direkt auf der Datenbank verhindern, über Unique Indexes. Ein mehrfaches Absenden desselben Forms kannst Du mit Javascript verhindern.
Mussfelder, in die der Benutzer zwingend etwas eingeben muss, müssen natürlich bei der Validierung auch berücksichtigt werden.

Stored Procedures brauchst Du nicht zwingend. Ich benutze sie, um mir die Arbeit zu vereinfachen - meine Lieblingsprozedur ist diejenige, welche für Hinzufügen und Ändern eines Records zuständig ist. In der Applikation kann ich dann den gleichen Code für beide Aktionen verwenden, und damit auch die gleiche Seite.

Deine Ausführungen tönen schon mal gut; noch ein paar Hinweise zu den einzelnen Punkten:

2. Ich würde die Tabelle nicht zu breit machen. Beim Benutzen stört es sehr, wenn man immer nach rechts und links scrollen muss. Je nach Datenmodell könnte es Sinn machen, einige Felder in der Tabellendarstellung wegzulassen oder die Datensätze mehrzeilig darzustellen.

2.2 Falls die Seite so lang ist, dass man nach unten scrollen muss, würde ich die Buttons oben und unten plazieren. Der Ändern-Button gehört eher direkt zum Datensatz in die Zeile, ebenso der Löschen-Button.

3. Genau die gleiche Seite kannst Du auch fürs Ändern verwenden. Der Unterschied besteht lediglich darin, dass beim Ändern das Formular mit den vorhandenen Daten vorgefüllt ist, und beim Speichern Update statt Insert verwendet wird.

3.1 Die Buttons sind üblicherweise mit "Speichern" und "Abbrechen" beschriftet.

3.2 Das Aktualisieren kann man auch automatisieren. So ist es für den Benutzer intuitiver. Die hinzugefügte Zeile soll einfach an ihrem Platz in der Tabelle erscheinen (gemäss Sortierung, sonst zuunterst). Falls Paging ohne flexible Sortierung angewendet wird, würd ich nach dem Hinzufügen automatisch zur letzten Seite springen, so dass der Benutzer die eben eingegebenen Daten sieht.

3.3 Es gibt nicht nur Fehler beim Hinzufügen ;-) Jede Datenbankaktion kann einen Laufzeitfehler verursachen.

4. Wenn der Löschen-Button direkt in der Datensatzzeile steht, ist es für den Benutzer einfacher.

4.2 Auch der Ändern-Button ist einfacher, wenn er direkt in der Datenzeile steht.

Was die Suche betrifft, so müsste zuerst mal festgelegt werden, welche Felder überhaupt suchbar sind. Je nachdem kann eine Filterfunktion sinnvoller sein. Auf jeden Fall sollten die Such- oder Filterresultate in der gleichen Tabellenform dargestellt werden, damit man von dort aus direkt ändern oder löschen kann.

Wenn das Datenmodell relativ einfach ist und nicht zuviele Felder enthält, könnten das Hinzufügen und Ändern sogar direkt in der Tabellenansicht erfolgen, statt über eine separate Seite. In den folgenden Links findest Du Beispiele hierzu und auch zum Paging, Sortierung und mehrzeiliger Bearbeitung. (Diese Beispiele sollen nur mögliche Darstellungen zeigen, sie basieren auf Dotnet).

http://de.gotdotnet.com/quickstart/aspplus.../datagrid6.aspx
http://de.gotdotnet.com/quickstart/aspplus.../DataList3.aspx
http://de.gotdotnet.com/quickstart/aspplus.../datagrid8.aspx
http://de.gotdotnet.com/quickstart/aspplus...datagrid11.aspx

Griessli
Irene
 
hallo Irene,
erstmals vielen Dank für Ihre Bemühung, mir zu helfen. Um ehrlich zu sein, das ist was ich gewartet habe, solche Tips, die Sie mir geschrieben haben, haben mir gefehlt und nirgendwo in anderen Foren gefunden habe. Vielen Dank.
Ich werde es mir merken, bisher klappt es mit der Verbindung zu dem SQL Server und die Seite mit der scrollbaren Tabelle funktioniert, ich bin jetzt mit dem Erstellen der Eingabeseite beschäftigt, natürlich habe ich eine Projektzeitplanung, so dass ich kontrollieren kann, wann ich schon fertig mit jeder einzelnen Phase fertig sein sollte. und immer wieder werde ich mich melden, falls Probleme. Es freut mich sehr, dass es Fachleute gibt, so wie Sie, die Interesse haben, ihre Erfahrungen weiterzuleiten. Schöne Grüße.
 
hallo Irene,
hier bin ich nochmal, etwas verwirrt mit dem Projekt. ich sehe nicht den Sinn, eine solche Datenbankeingabemaske für noch 3 oder 4 Benutzer, wenn der Administrator derjenige war und ist, der bisher die Daten gepflegt hat. Ich sehe nur den Sinn wenn der Benutzer etwas in der Datenbank in der ausgewählten Tabelle suchen möchte und da kann ich schon für das Suchen, eine Eingabemaske einsetzen, aber für das Hinzufügen, Löschen oder Ändern, sehe ich nicht sinnvoll.
Obwohl ich meine Meinung meinem "Betreuer" geäußert habe, besteht er darauf dass sowohl er als auch noch 3 Leuten das brauchen wedren und die Funktionen Hinzufügen, Löschen und Ändern dabei sein müssen.
In Wirklichkeit hatte mein "Betreuer" gar kein Projekt für mich, die DBEM ist was ihm einfach von Tag zu Tag eingefallen ist, als Thema für meine Diplomarbeit. Meiner Meinung nach weißt er nicht genau was er will, wenn mein Betreuer an der FH mich fragen sollte, hat es Sinn eine solche DBEM aufzubauen ?, wüßte ich nicht was für eine Antwort ich ihm sagen sollte.
Mein "Betreuer" hat mir erklärt, dass diejenigen, die die DBEM nutzen würden, würden diese nutzen, um nicht nur Daten auszulesen sondern auch um Daten einzugeben.
Ich stehe allein in dem Projekt und kriege keine Hilfe, um Rat in Foren zu bitten, hat mich nur gut gebracht, als ich Ihre Tips gelesen habe. Was würden Sie mir raten oder besser geschrieben, was meinen Sie darüber, was ich oben geschrieben habe?, für ein Tip oder Meinung wäre ich Ihnen dankbar. Gruß.
 
Erste Regel: der Kunde ist König ;-)

Ist er natürlich nicht wirklich, und in Deinem Fall ist es (noch) kein "richtiger" Kunde. Aber es schadet nichts, sich dieses Denken so früh wie möglich anzueignen. Wenn der Kunde - der kann auch intern sein, eine Abteilung oder eine Gruppe von Benutzern - für sich entscheidet, dass er eine bestimmte Funktionalität braucht, dann soll der Entwickler diese liefern. Natürlich soll ein Entwickler auch mitdenken, sich in die Situation des Benutzers versetzen und überlegen, was diesem den grössten Nutzen bringt. Entscheiden tut aber schlussendlich derjenige, der etwas anfordert (und meistens auch bezahlt...).

In diesem Fall bringt die DBEM schon für den Administrator etwas, weil die Anzeige und Eingabe über den Browser benutzerfreundlicher ist als über das DB-Managementsystem. Weiter ermöglicht eine solche DBEM auch anderen Personen die Benutzung (der Admin kann normalerweise anderen Personen keinen Zugriff auf das DB-Managementsystem erteilen, das wäre viel zu gefährlich). Und sobald mehrere Benutzer (auch gleichzeitig) daran arbeiten können, wird der Admin entlastet. Je nachdem, wieviel Arbeitslast die Pflege dieser Daten bedeutet, kann die Entwicklung einer DBEM sehr schnell rentieren.

Falls Dein Betreuer gleichzeitig der Admin ist, dann nehm ich mal an, der möchte sich mittelfristig ganz von dieser Arbeit entlasten ;-) Und das ist wahrscheinlich nichtmal so falsch, denn eigentlich müsste der anderes zu tun haben, als Daten eingeben.

Und für Dich ist das Ganze auf jeden Fall nützlich. Die Erfahrungen mit diesem Projekt wirst Du immer wieder brauchen können.

Griessli
Irene
 
hallo Irene,
danke für die Antwort, ja da haben Sie Recht, der Kunde ind diesem Fall der User ist der König. Das werde ich mir merken. Gruß.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben