Hallo ihr,
wer kennt eine URL, ein Buch, ein Schulungsangebot oder ähnliches zum Thema Datenbank-Qualitätssicherung.
Vielen Dank
JStefan
Qualitätssicherung von was genau?
Um was geht es dir:
Qualitätssicherng bzgl.
- DB-Design
- DB-Administration
- ???
Bitte kurze Erläuterung deines Problems, so dass ich mir ein Bild machen kann.
Danke,
Bernhard
Um was geht es dir:
Qualitätssicherng bzgl.
- DB-Design
- DB-Administration
- ???
Hallo Bernhard,
mir geht es um grundsätzliche Möglichkeiten, innerhalb eines Projektes die Qualität der DB zu testen. IMHO sollte/muss Qualität ja messbar sein. Ich frage mich daher, wie ich das DB-Design nach hergebrachten Standards qualifizieren kann. Das selbe gilt für die Qualität der applikationsseitigen Skripte und für die Konfiguration und Administration der DB / des RDBMS.
Ich habe mal im Bereich QS gearbeitet und bin jetzt im Oracle-Umfeld (SQL, PL/SQL, DBA) unterwegs. Da suche ich natürlich nach Wegen, diese beiden Gebiete zu verbinden …
Ansonsten schon jetzt vielen Dank für deine Hilfe.
Gruß JStefan
Qualitätssicherung DB-Design, DB-Admin
Hallo Stefan,
für DB-Design und die Entwicklung einer DB-Applikation gelten in meinen Augen die gleichen Methoden wie für die Software-Entwicklung allgemein. Dieses Thema ist beliebig komplex und umfangreich, und: Je wissenschaftlicher, um so schwieriger umzusetzen.
Meine Leib- und Magenlektüre dazu: „Lehrbuch der Software-Technik, Band II“ von Helmut Balzert (http://www.software-technik.de). Überblick über das gesamte Thema, Literaturverweise zu tieferen Studium, Teile kann man direkt in die Praxis übernehmen. Spezifische Ansätze für DB-Design habe ich in meinem Bücherschrank und im WWW nicht gefunden. Im Prinzip ist das natürlich denkbar: Für objektorientierte Systeme gibt es allgemeine, applikationsunabhängige Metriken (in der Praxis hat mir sowas allerdings noch nicht geholfen…), also könnte man derartige Ansätze auch für das relationale Paradigma entwicklen.
Ich realisiere Archivsysteme auf Basis Oracle in einem kleinen Team. Was die Qualität unserer Arbeit verbessert hat:
- Beim Pflichtenheft nicht hudeln, lieber ein Review zu viel, als einer zu wenig.
- Design nicht auf relationaler Ebene, sondern auf abstrakter Ebene: OMT, UML
- bei der konzeptionellen Arbeit ruhig mehrere Alternativen verfolgen, anschließend bewerten, die bessere verwenden
- validieren, wo möglich: Die DB-Bereiche, die Performanceprobleme vermuten lassen, implementieren, mit realen Datenmengen beleben (kleines PL/SQL-Programm, das Daten generiert, über Nacht anschmeissen) und Transaktionslast simulieren (PL/SQL mit DBMS_JOB, Aktionen und Last protokollieren)
- Code ist nicht wichtig, sondern 1a konzeptionelle Arbeit. Dann ist Code schreiben einfach und überschaubar.
- Kommunikation und Engagement im Team
Für DB-Administration gilt: Neben den QS-Methoden für SW-Entwicklung muss noch die organisatorische Seite geklärt sein. Ich sehe immer, dass es an beidem hapert: Der DBA wird von einem Problem überrascht, das sich eigentlich schon seit zwei Monaten angekündigt hat und heute zuschlägt. Vor lauter Hektik, die Kiste wieder ans Fliegen zu bringen, wird niemand informiert und nichts dokumentiert. Beim nächsten derartigen Fall weiß wieder niemand, was zu tun ist…
Wenn ich fremde DB-Designs beurteilen soll, und nur die DB vorliegen habe (keine Entwicklungsdoku), dann generiere ich mir ein IDEF1X- oder Krähenfußdiagramm und versuche, das Geflecht zu entwirren. Dann schaue ich mir die Sachen, die mir aufgefallen sind, im Detail an.
Leider kann ich keine Patentrezepte anbieten, hoffentlich ist trotzdem was dabei ist, was dir weiterhilft!
Grüße,
Bernhard *dermalwiederamzutextenwar*
Hallo Bernhardt,
vielen Dank für deine Tipps. Ich habe von Balzert das „Lehrbuch Grundlagen der Informatik“ und bin absolut begeistert vom Autor und seinem Stil. Ich werde mir daher das empfohlene Buch besorgen und versuchen, deine Hinweise umzusetzen.
Vielen Dank dafür.
Gruß JStefan