Implementierung von relationalen Datenbanksystemen und Denormalisierung.

Seminararbeit aus Informationswirtschaft Implementierung von relationalen Datenbanksystemen und Denormalisierung. Sommersemester 2001 Andrei Tchoubrikov, Matrikelnummer 9451840 Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 1/1

1 Einführung 3 1.1 Zielsetzung der Arbeit 3 1.2 Von der realen Welt zur Datenbank 3 2 Produktüberblick 5 2.1 Geschichtliche Entwicklung 5 2.2 Softwarepakete 5 2.3 Lizenzierung 7 2.3.1 Lizenzmodelle 7 2.3.2 MySQL 8 2.3.3 Pervasive 8 2.3.4 Adabas D 9 2.3.5 Oracle 9 2.3.6 Microsoft 10 2.3.7 Weitere DB-Anbieter: 10 3 Implementierung von Datenbanken 11 3.1 Das Datenbankschemata 3.2 Architektur des internen Schemas 11 12 3.3 Datenspeicherung 12 3.4 Portierung von Datenbanksystemen 14 3.5 Abfragenoptimierung 16 4 Denormalisierung 17 4.1 Theoretischer Hintergrund 4.2 Steigerung der Performance durch Denormalisierung 17 17 4.3 Denormalisierung in Data Warehouse 19 5 Literaturverzeichnis 20 Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 2/2

1 Einführung 1.1 Zielsetzung der Arbeit Die Seminararbeit basiert auf Kapitel 15 (Seiten 347 372) des Buches [Janko98] und soll das Thema mit Praxis-Beispielen anreichern. Das Ziel ist es nicht das Thema möglichst komplett darzustellen, sondern Nichtinformatikern die Komplexität und Struktur des Themas darzustellen und anhand von ausgewählten Bereichen die Risiken und Vorteile des Einsatzes in Unternehmen vorzuheben. Als Zielgruppe werden Studenten der Betriebswirtschaft angenommen. Volkswirte und Wirtschaftspädagogen werden als Betriebswirte angesehen. 1.2 Von der realen Welt zur Datenbank Bei der Modellierung einer Datenbank müssen mehrere Schritte durchgeführt werden. Ausgehend aus der realen Welt wird zuerst ein Ausschnitt ausgewählt, welches Abgebildet werden muss. Dieser Abschnitt wird z.b. mit der EER - Modell beschrieben. Bei jedem Überführen aus einem Vorgängermodell in das nächste findet Modell ein Informationsverlust statt. Gleichzeitig wird das Nachfolgermodell mit zusätzlichen Informationen erweitert (Informationsgewinn). So wird z.b. im EER - Modell festgelegt, dass die PERSON das BUCH liest und nicht einfach in den Händen hält oder verkaufen will, was in der realen Welt nicht eindeutig feststellbar ist. ER-Modell Rel. Modell DBS (SQL) Entität Relation Tabelle Attribut Attribut Spalte Entitätsexemplar Tuppel Zeile Beziehung Relation Tabelle / Spalte Primärschlüßel Primärschlüßel PRIMARY KEY - Fremdschlüssel FOREIGN KEY - - Index Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 3/3

Informationsverlust und gewinn findet auch bei der Implementierung des relationalen Modells in einer Datenbank statt. Aus einer Tabelle ist nicht ersichtlich, ob es sich um eine Entität oder eine Beziehung aus dem EER - Modell handelt. Eine Tabelle (Entität oder Beziehung) kann, um den Normalformen zu entsprechen, in mehrere Tabellen aufgeteilt werden, was die Lesbarkeit oder grafische Darstellung erschwert. Ein relationales Modell muss bei der Implementierung um zusätzliche Informationen erweitert werden, wie z.b. Feldtypen (Zeichenketten, Zahlen werte; flexible oder fixe Länge der Zeichenketten, Gültigkeitsbereiche der Zahlenwerte) und die Frage, ob die Werte für ein Attribut des EER - Modells vom Benutzer eingegeben werden kann, oder aus einer bestimmte Liste ausgewählt werden muss (führt zu zusätzlichen Tabellen). Eine weitere wichtige Erweiterung des Datenbank-Modells im Vergleich zum relationalen Modell stellt die Indexierung von Feldern dar. Ein Index stellt ein Schnellverzeichnis eines Feldes dar, ähnlich einem Stichwortverzeichnis in einem Buch. Beim Suchen nach einem indexierten Feld wird nicht die ganze Tabelle durchgearbeitet, sondern im Index nachgeschaut und gleich die relevanten Zeilen ausgegeben. Die besten Kandidaten für Indexierungen sind Primär-, Sekundär- und Fremdschlüssel aus dem relationalen Modell, aber auch Felder nach denen oft gesucht wird (z.b. Namen oder Adressen). Gut ausgewählte Indexe steigern die Leistung einer Datenbank stark und verringern die Antwortzeiten. Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 4/4

2 Produktüberblick 2.1 Geschichtliche Entwicklung Das erste am Mark erschienen DBMS war IMS/360 Version 1 der Firma IBM im Jahre 1968. Die ersten DBMS waren netzwerk oder hierarchisch und hatten den großen Vorteil, dass Daten von dem Anwendungsprogramm getrennt wurden. Das Anwendungsprogramm musste sich nicht mehr mit der Verwaltung von Daten beschäftigen und konnte sich auf den Kernbereich des Programm konzentrieren. Seit Anfang der 70 er Jahre wurde bei IBM an relationalen DBMS und der Datenbanksprache SQL gearbeitet. Das erste kommerziell verfügbare relationale DBMS erschien jedoch erst im Jahre 1980 und hieß ORACLE. Trotz Anfangsschwierigkeiten setzte sich das relationale Datenbankmodell durch. Gründe dafür waren die Einfachheit und Mächtigkeit des Modells, der Sprache SQL und die Verständlichkeit des Konzeptes von zweidimensionalen Tabellen mit Zeilen und Spalten. 2.2 Softwarepakete Datenbankmanagementsysteme werden selten alleine verkauft. Meist werden sie zusammen mit Administrations-, Diagnosewerkzeugen und anderen Tools in einem Paket verkauft. Zum Teil sind es Programme, welche die Datenbank verwenden, aber nicht Teil eines relationalen DBS sind (z.b. Data Warehouse-Komponenten, oder WWW-Server für die Datenbank). Eine Liste der Nebenprogramme von Microsoft SQL Server 2000 sei als Beispiel erwähnt 1 : Advanced Analysis Features for OLAP Clickstream Analysis Closed-Loop Analysis Comprehensive Analysis Services Data Mining Data Transformation Services Data Warehousing Alliance Distributed Partitioned Views English Query Extend Applications Full-Text Search 1 Quelle: http://www.microsoft.com/sql/howtobuy/choosing/default.asp, am 22.06.2001 Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 5/5

High Availability Indexed Views Integration with Microsoft.NET Enterprise Servers: BizTalk Server and Commerce Server Meta Data Services Office 2000 Integration Online Analytical Processing (OLAP) OLAP Flexibility Replication Rich XML Support Scalability Security Simplified Database Administration Virtual Interface System Area Network (VI SAN) Web Access to Data Web and Application Hosting Web-Enabled Analysis Diese Softwarepakete sind auf bestimmte Aufgaben und Benutzer ausgerichtet. ungefähre Einteilung ist z.b.: Embedded, Lite, Personal/Desktop, Standard, Enterprise. Eine Embedded Datenbankserver für Einbettung in eine Anwendung. Der Softwarehersteller kann sich die Datenverwaltung in seinem Programm ersparen und eine abgespeckte Version eines DBMS dafür verwenden. Meistens wird mit dem DBMS keine Werkzeuge mitgeliefert, sie ist nur lokal Lauffähig (keine Netzwerkversion) mit beschränkter Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 6/6

Benutzerzahl; das DBMS wird nicht als Dienst (Systemprogramm im Hintergrund) gestartet, sondern als ein normales Programm des Benutzers. Beispiel: ASAP-ToolSet von SAP verwendet Microsofts MSDE, ein abgespeckter SQL Server. Lite Eine leichte Version der Datenbank. Meistens wird ein Administrationswerkzeug mitgeliefert. Personal/Desktop Datenbankserver für den privaten Gebrauch. Der Server entspricht der Standard- Version, ist aber meistens nicht Netzwerkfähig oder mit sehr geringer Verbindungsmöglichkeiten. Standard Standardversion des Datenbankmanagementsystems. Zielgruppe sind Klein- und Mittelbetriebe, sowie größere Abteilungen. Komplette Ausstattung mit ein paar Sonderanwendungen (OLAP, Internet-Anbindung) Enterprise Professionelle Version für Rechenzentrumsbetrieb. Verfügt meistens über zusätzliche Diagnose-Werkzeuge, Back-up Lösungen und Sonderfunktionen des DBMS wie Unterstützung von großer Anzahl Prozessoren oder mehr Arbeitsspeicher. 2.3 Lizenzierung 2.3.1 Lizenzmodelle Die Modelle der Lizenzierung von Datenbankmanagementsystemen ist sehr vielfältig. Nahezu jeder Hersteller hat ein eigenes Modell. Meistens wird nach Softwarepaketen und unterstützter Plattform unterschieden. Das häufigste Modell ist die Lizenzierung der Server oder der Benutzer. Im Falle der Lizenzierung pro Server kann an einem Server das DBMS verwendet werden und die Anzahl der Benutzer, welche auf den Server zugreifen können, ist lizenzrechtlich unbegrenzt. Im Falle der Lizenzierung pro Benutzer bekommt ein Benutzer (Mitarbeiter der Firma) das Recht auf alle Server im Unternehmen zuzugreifen; die Anzahl der Server im Unternehmen sind lizenzrechtlich unbegrenzt. Die beiden Modelle schließen sich im allgemeinen aus. Es gibt aber Anbieter, welche pro Server und pro Benutzer Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 7/7

Lizenzierungen vornehmen. Einige Hersteller lizenzieren nicht pro Server, sondern pro Prozessor. Die Vergleichbarkeit der Lizenzgebühren erschwärt sich auch durch die unterschiedliche Größe der Softwarepakete. Fast alle Hersteller von DBMS - Systemen sind im Internet vertreten und bei einigen ist es sogar möglich Lizenzen online zu erwerben und die Software über das Internet zu bestellen oder runter zu laden. 2.3.2 MySQL Die Lizenzierung erfolgt pro Server (unabhängig von der Prozessor- oder Benutzeranzahl) 2. MySQL ist aus einem Open Source Projekt entstanden und wird von einer Gruppe Programmierer in Schweden weiter entwickelt. Die Nutzung für nichtkommerzielle Zwecke, insbesondere in der Wissenschaft, oder private Nutzung ist Lizenzfrei. Die Lizenzgebühren für die kommerzielle Nutzung sind sehr moderat. Der Hersteller bietet für kommerzielle Benutzer Support-Verträge an. # of licenses Cost per license 1 200 EURO 10 150 EURO 50 120 EURO 2.3.3 Pervasive Pervasive.SQL 2000i läuft unter den Betriebssystemen NetWare, Windows NT, Linux, Sun Solaris. Pervasive.SQL ist eine komplette relationale DBMS 3. Früher war das DBMS unter dem Namen Btrieve bekannt. Pervasive macht keine preisliche Unterschiede zwischen den unterstützten Plattformen. Lizenzierung erfolgt nur pro Benutzer für einen Server. Lizenzgebühren: Pervasive.SQL 2000i Server Edition for Windows NT - 10 User $1,195.00 Pervasive.SQL 2000i Server Edition for Windows NT - 20 User $2,095.00 Pervasive.SQL 2000i Server Edition for Windows NT - 50 User $4,595.00 2 Quelle: https://order.mysql.com/ am 25.06.2001 3 Quelle: https://www.pervasive.com/ecommerce/department/lookup.taf?_function=details&_id=26&_userreference= AC10004B46B4CB32AD5F2CE4D9D13B38E8A3 am 25.06.2001 Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 8/8

Pervasive.SQL 2000i Server Edition for Windows NT - 100 User $7,995.00 Pervasive.SQL 2000i Server Edition for Windows NT - Unlimited User $11,995.00 2.3.4 Adabas D Das RDBMS Adabas D wird von der Software AG aus Deutschland entwickelt und vertrieben. Das Lizenzierungsmodell orientiert sich gleichzeitig an der Server- und Benutzerzahl. 4 ADABAS D 10.0 Server-Systeme AEE100-713ALL ADABAS D 10.0 Server Entry Pack DBMS UNIX, Win NT und Win95 incl. 10 User-Lizenz Preis pro System 3.480,00 DM AEE-100-630ALL ADABAS D 10.0 Workgroup Ed. Datenbank-Server für Win NT, Win95, CD Pro User (min. 5 User) 500,00 DM ADABAS D 10.0 Client-Zusatzlizenzen AEE-100-631ALL ADABAS D 10.0 Workgroup Ed.100+ DB-Server (100 User) für Win NT, Win95, (CD, Lizenz) Preis pro User ab dem 100. User! 425,00 DM AEE-100-632ALL ADABAS D 10.0 Workgroup Ed.250+ DB-Server (250 User) für Win NT, Win95, (CD, Lizenz) Preis pro User Ab dem 250. User! 375,00 DM ADABAS D 10.0 fürs Internet/Intranet AEE100-620ALL ADABAS D 10.0 Web Server Pack Web Edition Für UNIX, Win NT, Win95 Lizenz pro System 4.990,00 DM 2.3.5 Oracle Oracle war der erste Anbieter von kommerziellen relationalen DBMS und gilt auch heute noch als Marktführer und Trendsetter im Datenbanken-Bereich. Oracle bietet zwei Modelle der Lizenzierung an 5 : Pro Prozessor oder pro Benutzer im Unternehmen. Zusätzlich fügt Oracle eine zeitliche Begrenzung der Gültigkeit der Lizenz: sie kann entweder als ewig, auf 4 Jahre oder auf 2 Jahre begrenzt erworben werden. 4 Quelle: http://www.carano.de/products/preislisten/sw-ag.html am 25.06.2001 5 Quelle: http://oraclestore.oracle.com/cec/cstage?eccookie=&template=help_licensing.en.htm am 25.06.2001 Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 9/9

Standard-Version FULL 2Y 4Y Processor 15,000 5,250 9,000 Named User 300 105 180 Enterprise -Version FULL 2Y 4Y Processor 40,000 14,000 24,000 Named User 800 280 480 2.3.6 Microsoft Microsofts SQL Server war eines der ersten Produkte, welcher auf Windows NT lief. Der SQL Server läuft ausschließlich auf Microsoft-Betriebssystemen (Windows NT/2000) und erreicht durch Ausnutzung der Dienste des Betriebssystems sehr gute Leistungswerte. Microsoft bietet zwei Lizenzmodelle an: 1. Pro Prozessor. Es wird eine Lizenz pro Prozessor des Servers benötigt, welcher Microsoft SQL Server verwendet. Benutzer, die auf den Server zugreifen brauchen keine Lizenzen. 2. Pro Benutzer und Server Es wird eine Lizenz für den Server benötigt, welcher Microsoft SQL Server verwendet. Zusätzlich braucht jeder PC, welcher auf den Server zugreift eine Client Access Licenses (CAL) SQL Server 2000 Enterprise Edition Standard Edition Developer Edition Processor Licensing Server/Per-Seat CAL License with 5 CALs with 10 CALs with 25 CALs $19,999 US per processor Not available Not available $11,099 US $4,999 US per processor $1,489 US $2,249 US Not available Licensed Per Developer $499 US Version/Competitive Upgrade with 5 CALs with 25 CALs Not available $5,549 US $749 US Not available 2.3.7 Weitere DB-Anbieter: Weitere bekannte Hersteller von Datenbankmanagementsystemen sind Centura (Gupta) Sybase (SQL Server) und IBN (DB2). Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 10/10

3 Implementierung von Datenbanken 3.1 Das Datenbankschemata Bei der Betrachtung eines Datenbanksystems wird zwischen drei Ebenen unterschieden: 1. Konzeptionelle Schicht 2. Externes Schema 3. Internes Schema In einem Datenbankmanagementsystem werden nur das externe und interne Schema implementiert. Die konzeptionelle Sicht wird mit zumeist mit EER modelliert. Das externe Schema ist bei den relationalen Datenbanken weitgehend durch die Datenbanksprache SQL (Structured Query Language) standardisiert. Die Standardisierung des externen Schemas durch die Sprache SQL bei relationalen Modell bildet eine einheitliche Schnittstelle der DBMS zu den Anwendungssystemen. Internes und externe Schemata. SQL als gemeinsame Kommunikation. Unterschiedlichkeit der Implementierungen. Inkompatibilität der DB-Dateien: Access-Datei kann nicht mit Oracle bearbeitet werden. Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 11/11

3.2 Architektur des internen Schemas Datenbankmanagementsysteme zählen zu den kompliziertesten Softwareprodukten. Die meisten DBMS basieren auf der Client/Server-Architektur und sind Modular aufgebaut. Die einzelnen Module, welche auch in separate Programme ausgelagert werden können, oder and Betriebsdienste, sind Schichtenweise angeordnet. Architektur des Microsoft SQL Server 7 als Beispiel für eine relationale DBMS. FRAGE: Die oberste Schicht in der Architektur ist die Netzwerkbibliothek. Es gibt auch meistens keine Administrationswerkzeuge. Warum? DBMS sind Server im Client/Server-Modell und laufen meistens als Hintergrundprozesse auf Servern. Alle Anwendungen (auch für Administration) greifen als Clients über das Netzwerk auf den Server zu. Dadurch ergeben sich keine Vorteile, physisch vor einem Server zu stehen und etwas am Server zu machen. 3.3 Datenspeicherung Es gibt kein einheitliches Format für Datenbanken. Grundsätzlich hat jedes Datenbanksystem, manchmal auch jeder Version eines Produktes, ein eigenes Dateiformat. Die Speicherung der Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 12/12

Daten erfolgt entweder in einer einheitlichen Datei, oder für jede Tabelle und Element der Datenbank wird eine separate Datei erstellt. Im Falle der Speicherung der Daten in eine einheitliche Datei wird diese in kleinere Teile, sogenannte Seiten mit einer festen Größe (meistens 2, 4 oder 8 KB), aufgeteilt. Dabei wird zwischen unterschiedliche Arten von Seiten differenziert: Datenseiten Indexseiten Binärseiten Zuordnungsseiten Die Datenseiten bestehen aus einem Seitenkopf mit administrativen Informationen und dem Daten-Teil. Die Daten werden Zeilenweise gespeichert, wodurch alle Felder einer Zeile zusammen gespeichert werden. Dies kann insoweit Einfluss auf die Performance des Datenbanksystems haben, dass unabhängig davon, ob nur ein Feld oder alle Felder abgefragt werden, das DBMS die gesamte Zeile von der Festplatte einliest. Fallbeispiel Datenübernahme Sie sind Mitarbeiter einer EDV-Abteilung und im Zuge einer Umstellung eines ERP-Systems müssen Sie Daten aus einer alten Datenbank in das neue DBMS übernehmen. 1. Welche Möglichkeiten haben Sie? 2. Worauf müssen Sie achten? 1. 1. Import/Export über gemeinsame Datenformate 2. Mit SQL (mit SELECT abfragen und INSERT Einfügen) Eine direkte Übernahme der Datenbank-Dateien ist idr nicht möglich. Das gemeinsamste Datenformat sind oft Textdateien mit fixierten Länge. Andere verbreitete Formate: dbase (*.dbf), DIF. ODBC und OLE DB eher mit Vorsicht zu genießen. 2. Die meisten Probleme bereiten bei Datenübernahmen die unterschiedlichen Formate und default - Werte der Importund Exportinstrumente und DBMS. 1. Feldlänge: a. Integer gleich groß, b. werden Strings abgeschnitten? 2. Codetabellen gleich? Besonders für Umlaute, Osteuropäische Sonderzeichen und kyrillische Buchstaben! Russisch hat 5 Codepages (bei falscher Codepage Text komplett nicht lesbar): 1. cp1251/windows, 2. cp866/dos, 3. koi8/unix Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 13/13

4. Macintosh 5. Unicode 3. Semantik a. Dezimalstellen durch Punkt oder Komma getrennt? b. Währungskennzeichen am Schluss? c. Strings in Trennzeichen? ( string oder string) Prozessgestaltung der Datenübernahme 1. Klar und detailierte Prozedur für Export und Import welches Programm mit welchen Einstellungen, Formate 2. TESTLÄUFE 3. Abgleich zwischen Altsystem und neuem System a. Saldenvergleich, b. Anzahl Datensätze. 4. Stichproben. 3.4 Portierung von Datenbanksystemen Die Möglichkeit ein Datenbanksystem auf mehreren unterschiedlichen Betriebssystemen verwenden zu können wird oft als ein Vorteil für den Benutzer und ein Wettbewerbsvorteil für das DBMS-Produkt angesehen. Neben der angenehmen Möglichkeit eine Datenbankdatei unter so unterschiedlichen Betriebssystemen wie zum Beispiel Unix, Windows und DOS aufzumachen und zu bearbeiten, bietet die Portierung von Datenbanksystemen den Unternehmen eine Möglichkeit an, ihre IT-Infrastruktur zu vereinheitlich. Es kommt oft vor, das einzelne Organisationseinheiten (Abteilungen, Tochtergesellschaften) ihre eigene IT-Infrastruktur aufbauen und dadurch zum Beispiel in einem Konzern unterschiedliche Server-Betriebssysteme (Linux, Novell, Windows NT/2000) und Datenbanksysteme verwendet werden. Die Verwendung eines portierbaren Datenbanksystem als einheitlichen Standard erlaubt mittelfristig die Nutzung der Datenbanksystemen zu optimieren (Erfahrungsaustausch), und langfristig alle Datenbanken in eine zentrale Stelle auszulagern und dadurch Kosten einzusparen. Der Nachteil von portierbaren Datenbanksystemen ist das Problem den größten gemeinsamen Nenner der unterstützten Betriebssystemen zu finden. Unterschiedliche Betriebssysteme verfolgen meistens unterschiedliche Philosophien und bieten unterschiedlich Instrumente und Dienste an. Um ein einheitliches Programm zu erstellen wird dabei im Programm selber entweder Dienste angeboten, welche bei einem konkreten BS nicht verfügbar sind, bei Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 14/14

anderen schon. Das andere Extrem ist die Duplizierung von BS-Diensten durch das DBMS um die Portabilität nicht zu verletzen. Die Aufgabe des Portabilitätszieles erlaubt eine stärkere Integration mit dem Betriebssystem mit effektiverer Nutzung der Dienste und schlussendlich der Ressourcen des Computers. Ein Beispiel für ein effizientes nicht portierbares DBMS liefert Microsoft SQL Server, welcher nur auf Microsoft Windows NT und 2000 läuft. Oracle8 and Oracle8i Standard Edition Platform Availability 6 Operating System Processor Hardware Bull Compaq OpenVMS, Compaq Tru-64 Unix PowerPC Alpha Data General DG-UX Intel Any, up to 4 CPUs* Fujitsu Hewlett-Packard HP-UX IBM/Motorola AIX SPARC PA-RISC PowerPC Microsoft Window NT,2000 Intel Any, up to 4 CPUs* NCR MP-RAS Intel Any, up to 4 CPUs* Novell NewWare Intel Any, up to 4 CPUs* SCO UnixWare Intel Any, up to 4 CPUs* Siemens Nixdorf, SINIX/Reliant UNIX MIPS Escala S series: S100 Escala E series: E230,E250 Escala T series: T430,T450 EPC: 430, 450 (up to a maxumim capacity of 4 cpus) Compaq AlphaServer 800, 1000A, 1000, DS10, DS20, DS20E, ES40 Any PRIMEPOWER (GP7000F), 200, 400 up to a maximum capacity of 4 CPUs HP9000 a-class: A400, A500 r-class: R380, R390 d- class: D220, D230, D270, D280, D320, D330, D370, D380, D390 l-class: L1000, L2000, L3000 hp Unix workstations : j-class/c-class/b-class RS/6000: 43P, 44P, 42T/42W, B50, B80, C10, C20, E30, F30, F40, F50, H10, H50, H70 pseries 640, 620 Model 6F0 (only), 660 Model 6H0 (only) Motorola RISC PC Plus Series, EX Series, PowerStack II Pro2000, Pro3000, Pro4000 SNI RM200, RM300 SGI IRIX MIPS O2, Octane, Origin200 (Single Tower Only) Sun Solaris Intel Intel Any, up to 4 CPUs* Sun Solaris SPARC SPARC Any, up to a maximum capacity of 4 CPUs 6 Quelle: http://www.oracle.com/ip/deploy/database/availability/index.html, am 25.06.2001 Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 15/15

3.5 Abfragenoptimierung Die Optimierung von Abfragen ist wichtiger Bestandteil des Datenbanksystems und hat einen entscheidenden Einfluss auf die Performance eines DBMS. Weder das relationale Modell, noch der Standard SQL bestimmen wie das relationale Modell implementiert werden muss. Bei schlechter Implementierung (z.b. Fehlen von Abfrageoptimierer, Caches etc.) können Abfragen unverhältnismäßig lange Antwortzeiten haben und die Ressourcen (Prozessor, Arbeitsspeicher) stark belasten. Die Aufgabe des Abfrageoptimierers ist es die SQL - Anfrage zu analysieren und nach bestimmten Entschidungsregeln die SQL - Abfrage in eine Anweisung im internen Datenbank-Format zu übersetzen, welche dann ausgeführt wird. Die Entscheidungsregeln können z.b. Optimierungsvorgaben sein, möglichst arbeitsspeicherschonend vorzugehen, oder die Antwortzeit zu optimieren. Zur Optimierung werden Statistiken über die Tabellen geführt (Größe der Tabelle, Verteilung der Feldinhalte, etc.) oder die Tabellendefinition verwendet (Verwendung von Indizes) Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 16/16

4 Denormalisierung 4.1 Theoretischer Hintergrund Als Vorteile der Normalisierung gelten die klare Struktur der Datenbank, die Vermeidung von Redundanzen und die Vermeidung von Anomalien beim Einfügen, Löschen oder Ändern von Informationen. Die Normalformen sind wie folgt definiert: 1. Normalform Eine Relation ist in 1. Normalform, wenn jedes Tupel der Relation je Komponente nur einen Wert aus dem Wertebereich des Attributs aufweist. 2. Normalform Eine Relation befindet sich in der 2. Normalform, wenn diese sich in der 1. Normalform befindet, und jedes nicht zum Schlüssel gehörende Attribut von diesem voll funktional abhängig ist. 3. Normalform Eine Relation ist in 3. Normalform, wenn sie in 2. Normalform ist und es kein Attribut, welches nicht Teil des Schlüssels ist, gibt, welches transitiv vom Schlüssel abhängt Mit steigender Normalform verteilt sich eine Datenbank tendentiel auf mehr immer mehr Relationen (Tabellen in DBMS). Dies führt bei Abfragen zur vermehrte Verwendung von JOIN Operationen. Bei fehlen, oder ineffektivem, eines Abfragenoptimierer oder großen Datenmengen belasten JOIN Operationen das System beträchtig und wirken sich negativ auf Antwortzeiten des gesamten Systems aus. 4.2 Steigerung der Performance durch Denormalisierung Da weder das relationale Modell, noch SQL bestimmen wie das relationale Modell implementiert werden soll. Bei schlechter Implementierung (z.b. Fehlen von Abfrageoptimierer, Caches etc.) können Abfragen unverhältnismäßig lange Antwortzeiten haben und die Ressourcen (Prozessor, Arbeitsspeicher) stark belasten. Besonders stark kann sich das bei JOIN - Operationen auswirken, welche in den relationen Datenbanken sehr oft vorkommen. Der JOIN kann jedoch vermieden werden, indem während des Einfügens von neuen Daten in die Datenbank eine separate Tabelle gefüllt wird, welche das Ergebnis des JOINs beinhaltet. Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 17/17

Bei der Abfrage der Daten wird kein JOIN von Tabellen gemacht, sondern mit einem einfacher SELECT - Abfrage die Daten abgelesen. Als Anwendungsbereiche bieten sich alle Allgemeine Übersichten (Produktkataloge, Inhaltsverzeichnisse, Liste der Beiträge eines Diskussionsforums, etc.). Ökonomische Erklärung Die Kosten der normalisierten und denormalisierten Modelle können durch mathematische Funktionen dargestellt werden. Die Kostenkurve des normalisierten Modells verläuft linear ohne Fixkosten. Die Kostenkurve des denormalisierten Modells verläuft auch linear, jedoch mit einer geringeren Steigerung, und einem Fixkostenanteil (Kosten der Einfügung). Leistungsgewinn: Leistungssteigerung: <<Anzahl Zugriffe>> * (<<Abfrage Norm>> - <<Abfrage Denorm>>) - <<Kosten der Einfügung>> <<Anzahl Zugriffe>> * <<Abfrage Norm>> <<Anzahl Zugriffe>> * <<Abfrage Denorm>> + <<Kosten der Einfügung>> Bei steigender Anzahl der Zugriffe tendiert der Fixkosten-Anteil gegen Null und die Leistungssteigerung nähert sich dem Faktor <<Abfrage Norm>> / <<Abfrage Denorm>>. 6000 5000 4000 3000 2000 1000 0 2,500 2,000 1,500 1,000 0,500 0,000 1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 Modell Norm Modell Denorm Leistungssteigerung (Rechte Skala) Beispiel: Abfrage Normalisiert= 50, Abfrage Denormalisiert= 20, Kosten der Einfügung= 250 Anzahl der Zugriffe 1 5 50 500 Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 18/18

Modell Norm 50 250 2500 25000 Modell Denorm 270 350 1250 10250 Leistungsgewinn -220-100 1250 14750 Leistungssteigerung 0,185 0,714 2 2,439 Durch die Denormalisierung bei häufig vorkommenden Abfragen eines Datenbanksystems entstehen folgende Vorteile: 1) geringere Belastung des Servers, 2) verbesserte Antwortzeiten des Systems, 3) Verwendung eines nicht optimalen Datenbankmanagementsystems möglich (ältere Version, welche nicht aktualisiert wird oder billigere, im Extremfall Freeware, Software). Die Nachteile der Denormalisierung sind 1) höherer Verwaltungsaufwand (Dokumentation, Handhabung in der Anwendung), 2) Komplikation der Anwendung durch Verwendung denormalisierten Tabellen und 3) erhöhter Speicherplatzverbrauch. Beim Umsteigen auf ein effektiveres Datenbankmanagementsystem (Aktualisierung oder Produktwechsel) und dem Wegfall der Vorteile der Denormalisierung kann die denormalisierte Tabelle durch einen View in der Datenbank ersetzt werden. Dadurch wird kein Speicherplatz mehr belegt (3.Nachteil, siehe oben) und es ist keine Änderung in der Anwendung notwendig (2.Nachteil, siehe oben). 4.3 Denormalisierung in Data Warehouse Data Warehouses werden zur Analyse von Zusammenhängen von Daten verwendet, z.b. von Daten aus Transaktionssystemen. Dabei werden die Daten bei der Übernahme aus den Basissystemen entsprechend definierten Regeln aufbereitet. Eine häufige Aufbereitung stellt die Summierung und Gruppierung von einzelnen Vorfällen. Diese sind beim relationalen Modell nicht notwendig (sie können in SQL-Abfragen mit arithmetischen Funktionen, wie z.b. COUNT(), MIN(), MAX(), u.s.w. errechnet werden.) und stellen eine Denormalisierung dar. Dabei wird eine Information, je nachdem von welcher Seite sie betrachtet werden, mehrmals gerechnet und abgespeichert. Es kommt zur Informations-Redundanz, nicht jedoch zu einer Daten-Redundanz, da der wert für die Schnittmenge nicht explizit abgespeichert wirdt. Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 19/19

Abbildung X. Mehrmalige Berücksichtigung von Informationen in Data Warehouse 5 Literaturverzeichnis [Janko98] Informationswirtschaft 1, 2. Auflage, Wolfgang Janko. Verlag Springer, 1998 [Soukup00] Inside Microsoft SQL Server 7.0, Kalen Delaney und Ron Soukup, Microsoft Press Verlag, 2000 [MySQL00] Dokumentation von MySQL, Internet http://www.mysql.com/ [Kaiser00] Lehrunterlagen PS/VO Management und Informationssysteme, SS2001 A. Kaiser, http://wwwai.wu-wien.ac.at/~kaiser/mis/, am 25.06.2001 [Stucky83] Datenbanksysteme : Konzepte und Modelle, G.Schlageter und W.Stucky, Teubner Studienbücher, Stuttgart 1983 Seminararbeit A.Tchoubrikov (9451840), relationale Datenbanken und Denormalisierung 20/20