Suche

» erweiterte Suche » Sitemap

Technik


» Bild vergrößern
» Blick ins Buch
» weitere Bücher zum Thema


» Buch empfehlen
» Buch bewerten
Produktart: Buch
Verlag:
Diplomica Verlag
Imprint der Bedey & Thoms Media GmbH
Hermannstal 119 k, D-22119 Hamburg
E-Mail: info@diplomica.de
Erscheinungsdatum: 04.2013
AuflagenNr.: 1
Seiten: 108
Abb.: 23
Sprache: Deutsch
Einband: Paperback

Inhalt

Ein häufig auftretendes Problem bei der Durchführung von IT - Projekten ist die aufgrund des Zeitdruckes nur mangelhaft durchgeführte Dokumentation, sowie der darauf aufbauende Wissenstransfer. Im Vordergrund der vorliegenden Studie steht die Implementierung eines Systems, welches den funktionalen Anforderungen des Kunden in Hinblick auf Qualität, Zeit und Preis entspricht wobei für die Projektdokumentation im Allgemeinen sowie für den Wissenstransfer im Besonderen häufig noch klassische Dateisysteme verwendet werden. Dies hat einerseits erhebliche negative Auswirkungen auf die Weiterentwicklung und Wartbarkeit des fertiggestellten IT-Systems beim Auftraggeber und ist ein Systemrisiko da das systemspezifische Wissen in den Köpfen der implementierenden Projektmitglieder zentriert ist. Andererseits sind auch die Mitglieder des durchführenden Projektteams und deren Organisation von einem suboptimal durchgeführten Wissenstransfer sowohl im laufenden Projekt als auch in den nachfolgenden Projekten negativ betroffen, da die aus einem Projekt erworbene Problemlösungskompetenz und - kapazität hinter ihrem möglichem Niveau zurück bleibt. Wissen und dessen Transfer stellt somit eine Herausforderung auf IT-Projekten dar.

Leseprobe

Textprobe: Kapitel 3.4, Datenbank: In Kapitel 3.4.1 werden die Bestandteile einer Datenbank kurz erläutert. Anschließend wird in Kapitel 3.4.2 auf die gängige Vorgehensweise bei der Entwicklung eines Datenmodells eingegangen. Aufgrund ihrer weiten Verbreitung und Bedeutung wird das relationale Datenmodell in Kapitel 3.4.3 behandelt. 3.4.1, Bestandteile: Wenn umgangssprachlicher von einer ‘Datenbank’ gesprochen wird, dann ist üblicherweise der Überbegriff ‘Datenbanksystem’ gemeint. Ein Datenbanksystem besteht im Wesentlichen aus folgenden Bestandteilen: -einem Datenbankverwaltungssystem und -einer Datenbank. Dazu kommen noch zusätzliche Programme kommen, die die Bearbeitung, Verwaltung und Auswertung der gespeicherten Daten vereinfachen. 3.4.1.1, Datenbankverwaltungssystem: Das Datenbankverwaltungssystem ist ein Softwaresystem zur Verwaltung eines Datenbestands, welches üblicherweise auch den gleichzeitigen Zugriff von mehreren Benutzern und Anwendungsprogrammen ermöglicht. Das Datenbankverwaltungssystem dient auch zur Administration der Daten des Datenbestandes selbst, wozu beispielsweise die Definition Attributen und deren Datentypen, die Festlegung von Zugriffsrechten usw. gehören. Während die Probleme der Datenspeicherung und des gleichzeitigen Zugriffs zentral durch das Datenbankverwaltungssystem gelöst werden, erfolgt die Verarbeitung und Auswertung der Daten durch Anwendungsprogramme, die über das Datenbanksystem auf die Daten zugreifen und diese verändern können. 3.4.1.2, Datenbank: Eine Datenbank hat charakteristischerweise einen zentral gespeicherten Datenbestand, welcher über anwendungsunabhängige Zugriffsverfahren weitgehend auch zentral verwaltet wird. Damit eine Datenbank von mehreren Anwendungen genutzt werden kann, wird ein anwendungsübergreifendes Datenmodell festgelegt, das den betrachteten Realitätsausschnitt widerspiegelt. 3.4.2, Datenmodell eines Datenbanksystems: Einer der ersten Tätigkeiten bei der Entwicklung eines Datenbanksystems ist der Entwurf eines Datenmodelles. Die Absicht der Datenbankmodellierung liegt darin, Objekte und Prozesse der realen Welt in Strukturen der Datenbank umzuwandeln. Eine der größten Herausforderungen dabei ist es, dass Datenbankdesigner, Anwendungsentwickler und Endanwender die nach der Inbetriebnahme der des Datenbanksystems zu verwaltenden Daten jeweils unter anderen Gesichtspunkten sehen. Datenbanksysteme bestehen meistens aus drei Softwareschichten, welche in folgender Reihenfolge erstellt werden: -Mittlere Schicht -Untere Schicht -Obere Schicht Das Dreischichtenmodell hat das Ziel, die physische und logische Datenunabhängigkeit eines Datenbanksystems zu gewährleisten, wobei die Trennung der Anwendungsprogramme von der Datenhaltung im Vordergrund steht. -Physische Datenunabhängigkeit (oder Implementierungsunabhängigkeit): Ziel ist hierbei, die konzeptionelle Schicht von der für die Speicherung der Daten gewählten Datenstruktur zu entkoppeln. Eine Veränderung der physischen Speicherstruktur verlangt somit keine Veränderung des Anwendungsprogramms und umgekehrt. -Logische Datenunabhängigkeit (Anwendungsunabhängigkeit): Das Ziel liegt hierbei, das Datenbanksystem von Änderungen und Erweiterungen der Anwendungsschnittstellen zu entkoppeln und umgekehrt. 3.4.2.1, Mittlere Schicht: Diese nennt man auch das konzeptionelle Schema oder konzeptionelles Modell. Das konzeptionelle Schema ist das Ergebnis der Abbildung eines konzeptionellen Datenmodells in ein konkretes Datenmodell, da in einem bestimmten Datenbanksystem implementiert werden soll. Dieser Prozess wird in der Folge skizziert: A.) Konzeptionelles Datenmodell Einer der ersten Tätigkeiten bei der Entwicklung eines Datenbanksystems ist der Entwurf eines konzeptionellen Datenmodelles. Die heute wichtigste und am weitesten verbreitete Beschreibungssprache für konzeptionelle Datenmodelle sind Entity- Relationship-Diagramme, die auf einem einfachen, zugrunde liegenden Datenmodell, dem Entity-Relationship-Modell (ER - Modell) beruhen. ER - Modelle bieten in der Form von ER - Diagramme eine leicht verständliche grafische Notation, die sowohl für Anwendungsexperten als auch Umsetzungsexperten gleichermaßen geeignet ist. Dabei sind ER-Modelle unabhängig von einem bestimmten Datenbankverwaltungssystem. Entitäten (z.B. die Person ‘Hermann Maier’) wird in Form eines Entitätstyps (z.B. ‘Person’) in einem Rechteck im ER-Diagramm eingezeichnet. Die für eine Anwendung relevanten Merkmale der Ausprägungen, wie zum Beispiel Name, Mitarbeiternummer, Geburtsjahr, etc. werden als Attribute der Entitätstypen bezeichnet und als Ovale im ER-Modell eingezeichnet. Ein weiteres wichtiges Konstruktionselement neben den Entitätstypen sind Beziehungstypen, die mögliche Beziehungen zwischen Entitäten definieren. Diese werden meist durch Zeitwörter benannt und im ER-Diagramm in Form von Rauten dargestellt. Das bei der Entwicklung eines Informationssystems entworfene konzeptionelle Datenmodell beschreibt die Dateien und ihre Beziehungen untereinander, im Unterschied zur untern Schicht, in einer Hardware- und betriebssystemunabhängigen Weise. Damit trennt es den logischen Aufbau des Datenbanksystems von seiner programmierungstechnischen Verwirklichung. Beispielsweise wird der logische Aufbau der Sätze in den einzelnen Dateien beschreiben, aber die tatsächliche Anordnung der Satzteile, ihre Länge in Bytes und andere technische Einzelheiten werden nicht benannt. Am konzeptionellen Modell lässt sich ablesen, welche Arten von Informationen sich der Datenbank generell entnehmen lassen und den Weg, wie man zu ihnen gelangt. Auch diese Schicht ist dem Benutzer üblicherweise nicht zugänglich.

Über den Autor

Mag. Gernot Sailer, B.A. wurde 1969 in St. Pölten geboren. Sein Studium der Betriebswirtschaftslehre an der Wirtschaftsuniversität Wien mit Spezialisierung auf Unternehmensführung und Steuerlehre schloss der Autor im Jahre 1996 ab. Danach arbeitete er bei einer der führenden Wirtschaftsprüfungsgesellschaften bis zur Ablegung der Steuerberaterprüfung. Die darauffolgenden zwei Jahre verbrachte er mit der Durchführung von Projekten in der Produktivitätsberatung, wo der Schwerpunkt auf operativer Kosten- und Durchlaufzeitenoptimierung liegt. Seit 2004 befasst sich der Autor beruflich mit der Planung sowie Implementierung von ERP-Projekten und war dabei auch als Projektleiter für die Umsetzung verantwortlich. Im Zuge seiner Tätigkeiten bemerkte er die steigenden Anforderungen an die Projektdokumentation sowohl von Seiten des Gesetzgebers und prüfender Organe als auch von Seiten des Kunden. Auch hausinterne Stellen (Riskmanagement, Qualitätssicherung, Knowledgemanagement, etc.) und Mitglieder des Projektteams des Beratungsunternehmens (Funktionelle Berater, Softwarearchitekten, Entwickler, etc.) stellen Anforderungen an die Projektdokumentation, häufig schon zu einem Zeitpunkt, an dem der Starttermin der eigentlichen Konfiguration und Entwicklung im System noch nicht fix, terminisiert oder beauftragt ist. Eine der Möglichkeiten, um diese steigenden Dokumentationsanforderungen bei IT-Projekten zu erfüllen, ist die Implementierung einer Wissensdatenbank, was auch die Thematik der Studie des Autors darstellt. Die Studie wurde an der Ferdinand Porsche Fachhochschule im Jahre 2012 mit dem Einfluss der beruflichen Erfahrungen des Autors erstellt.

weitere Bücher zum Thema

Bewerten und kommentieren

Bitte füllen Sie alle mit * gekennzeichenten Felder aus.