ΕΘΝΙΚΟ ΜΕΤΣΟΒΙΟ ΠΟΛΥΤΕΧΝΕΙΟ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΤΕΧΝΟΛΟΓΙΑΣ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ

ΕΘΝΙΚΟ ΜΕΤΣΟΒΙΟ ΠΟΛΥΤΕΧΝΕΙΟ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΤΕΧΝΟΛΟΓΙΑΣ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΥΠΟΛΟΓΙΣΤΩΝ ΖΩΓΡΑΦΟΥ 157 73, ΑΘΗΝΑ ΕΒΓ - ΙΠΛ-2001-07 Σεπτέµβρης 2001 ΜΕΛΕΤΗ & ΣΥΓΚΡΙΣΗ ΑΛΓΟΡΙΘΜΩΝ ΓΙΑ ΛΕΙΤΟΥΡΓΙΕΣ ΕΠΑΥΞΗΤΙΚΗΣ ΕΞΑΓΩΓΗΣ(INCREMENTAL EXTRACTION) Ε ΟΜΕΝΩΝ ΑΠΟ RDBMS ηµήτρης Βουδούρης ΕΠΙΒΛΕΠΩΝ ΚΑΘΗΓΗΤΗΣ: Τίµος Σελλής ΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ ΕΡΓΑΣΤΗΡΙΟ ΣΥΣΤΗΜΑΤΩΝ ΒΑΣΕΩΝ ΓΝΩΣΕΩΝ ΚΑΙ Ε ΟΜΕΝΩΝ

2

Στην οικογένειά µου! Ευχαριστώ του κυρίους Τ. Σελλή, A. Σιµιτσή και Ν. Καραγιαννίδη για την πολύτιµη βοήθεια που µου παρείχαν κατά την εκπόνηση της διπλωµατικής αυτής εργασίας, καθώς και όλα τους υπεύθυνους (και µη) του εργαστηρίου για τις πολύτιµες συµβουλές,πάνω σε τεχνικά θέµατα, που µου προσέφεραν. 3

4

ΠΕΡΙΕΧΟΜΕΝΑ 5

Πίνακας Περιεχοµένων ΚΕΦΑΛΑΙΟ 1 : ΕΙΣΑΓΩΓΗ...9 1.1) ΑΝΤΙΚΕΙΜΕΝΟ ΤΗΣ ΙΠΛΩΜΑΤΙΚΗΣ...10 1.1.1) Γενική περιγραφή...10 1.1.2) Συνεισφορά...10 1.2) ΟΡΓΑΝΩΣΗ ΤΟΥ ΤΟΜΟΥ...11 ΚΕΦΑΛΑΙΟ 2 : ΠΕΡΙΓΡΑΦΗ ΠΡΟΒΛΗΜΑΤΟΣ...12 2.1) ΕΙΣΑΓΩΓΗ...13 2.2) ΑΠΟΘΉΚΕΣ Ε ΟΜΈΝΩΝ & ΣΥΣΤΉΜΑΤΑ OLAP...13 2.3) ΕΠΑΥΞΗΤΙΚΉ ΕΞΑΓΩΓΉ(INCREMENTAL EXTRACTION)...18 KΕΦΑΛΑΙΟ 3 : ΘΕΩΡΗΤΙΚΗ ΠΕΡΙΓΡΑΦΗ ΑΛΓΟΡΙΘΜΩΝ...19 3.1) ΕΙΣΑΓΩΓΉ...20 3.2) ΘΕΩΡΗΤΙΚΉ ΠΕΡΙΓΡΑΦΉ ΤΗΣ ΜΕΘΌ ΟΥ ΑΝΆΛΥΣΗΣ ΤΩΝ LOGS...20 3.2.1) Περιγραφή των αρχείων log και χρησιµότητα τους...20 3.2.2) Εκµετάλευση των logs για την απόσπαση πληροφοριών σχετικών µε τις αλλαγές που έχουν γίνει στη βάση-incremental extraction...21 3.2.3) Log mining µέσα από την Oracle...22 3.2.4) Θεωρητικά πλεονεκτήµατα της µεθόδου...23 3.2.5) Θεωρητικά µειονεκτήµατα της µεθόδου...23 3.3) ΘΕΩΡΗΤΙΚΉ ΠΡΟΣΈΓΓΙΣΗ ΤΗΣ ΜΕΘΌ ΟΥ ΣΥΝΕΧΟΎΣ ΠΑΡΑΚΟΛΟΎΘΗΣΗΣ ΤΗΣ ΒΆΣΗΣ-TRIGGERS...23 3.3.1) Γενική περιγραφή της µεθόδου...23 3.3.2) TRIGGERS στην Oracle...24 3.3.3) Θεωρητική περιγραφή πρώτης εκδοχής...25 3.3.4) Θεωρητική περιγραφή δεύτερης εκδοχής-timestamps...25 3.3.5) Θεωρητικά πλεονεκτήµατα των µεθόδων µε τα TRIGGERS...27 3.3.6) Θεωρητικά µειονεκτήµατα των µεθόδων µε τα TRIGGERS...28 3.3.7) Σύγκριση µεταξύ των δύο διαφορετικών εκδοχών: triggers & timestamps28 3.4) ΘΕΩΡΗΤΙΚΉ ΠΡΟΣΈΓΓΙΣΗ ΤΗΣ ΜΕΘΌ ΟΥ ΜΕ ΤΑ SNAPSHOTS....29 3.4.1) Γενική περιγραφή της µεθόδου...29 3.4.2) Υλοποίηση των στιγµιοτύπων στην ORACLE...30 3.4.3) Θεωρητική περιγραφή της πρώτης εκδοχής-crc...31 3.4.4) Θεωρητική περιγραφή της δεύτερης εκδοχής-...32 Window algorithm...32 3.4.5) Θεωρητικά µειονεκτήµατα και πλεονεκτήµατα των µεθόδων χρήσης των snapshots...34 3.4.6) Σύγκριση µεταξύ των δύο διαφορετικών εκδοχών της µεθόδου...35 3.5) ΘΕΩΡΗΤΙΚΉ ΣΎΓΚΡΙΣΗ ΌΛΩΝ ΤΩΝ ΠΑΡΑΠΆΝΩ ΠΡΟΣΕΓΓΊΣΕΩΝ(LOGS, TRIGGERS- TIMESTAMPS, SNAPSHOTS)...35 ΚΕΦΑΛΑΙΟ 4 : ΥΛΟΠΟΙΗΣΗ ΤΩΝ ΑΛΓΟΡΙΘΜΩΝ...37 4.1) ΕΙΣΑΓΩΓΉ...38 6

4.2) ΠΕΡΙΒΆΛΛΟΝ ΥΛΟΠΟΊΗΣΗΣ ΤΩΝ ΜΕΘΌ ΩΝ...38 4.3) ΠΡΑΚΤΙΚΉ ΥΛΟΠΟΊΗΣΗ ΤΗΣ ΜΕΘΌ ΟΥ ΑΝΆΛΥΣΗΣ ΤΩΝ LOG FILES...38 4.3.1) Εργαλεία που χρησιµοποιούνται-περιγραφή Logminer,export/import...38 4.3.2) Στοιχεία που προστίθενται στη βάση για την υποστήριξη της µεθόδου...40 4.3.3) Περιγραφή υλοποίησης µεθόδου ανάλυσης των logs...42 4.4) ΠΡΑΚΤΙΚΉ ΥΛΟΠΟΊΗΣΗ ΜΕΘΌ ΟΥ ΧΡΉΣΗΣ TRIGGERS...55 4.4.1) Εργαλεία που χρησιµοποιούνται από τις δύο εκδοχές της µεθόδου- Περιγραφή των TRIGGERS της ORACLE & SEQUENCES...55 4.4.2) Στοιχεία που προστίθενται στη βάση µας για την υποστήριξη της πρώτης εκδοχής της µεθόδου...60 4.4.3) Περιγραφή υλοποίησης πρώτης εκδοχής...61 4.4.4) Στοιχεία που προστίθενται στη βάση µας για την υποστήριξη της δεύτερης εκδοχής της µεθόδου...68 4.4.5) Περιγραφή υλοποίησης δεύτερης εκδοχής...69 4.5) ΠΡΑΚΤΙΚΉ ΥΛΟΠΟΊΗΣΗ ΤΗΣ ΜΕΘΌ ΟΥ ΧΡΉΣΗΣ SNAPSHOTS....77 4.5.1) Εργαλεία που χρησιµοποιούνται από τις δύο εκδοχές της µεθόδου....77 4.5.2) Απλοποιήσεις και παραδοχές που υιοθετήσαµε...79 4.5.3) Στοιχεία που προστίθενται στη βάση µας για την υποστήριξη της µεθόδου.80 4.5.4) Περιγραφή υλοποίησης της πρώτης εκδοχής της µεθόδου-χρήση CRC...82 4.5.5) Στοιχεία που προστίθενται στη βάση µας για την υποστήριξη της δεύτερης εκδοχής της µεθόδου...87 4.5.6) Περιγραφή υλοποίησης της δεύτερης εκδοχής της µεθόδου-window algorithm...88 ΚΕΦΑΛΑΙΟ 5 : ΠΕΙΡΑΜΑΤΑ & ΜΕΤΡΗΣΕΙΣ...93 5.1) ΕΙΣΑΓΩΓΉ...94 5.2) ΠΑΡΆ ΕΙΓΜΑ ΕΚΤΈΛΕΣΗΣ...94 5.2.1) Περιγραφή υλικού...94 5.2.2) Περιγραφή σχήµατος της βάσης δεδοµένων που χρησιµοποιήθηκε...94 5.2.3) Αποτελέσµατα...95 5.3) ΠΕΙΡΑΜΑΤΙΚΈΣ ΜΕΤΡΉΣΕΙΣ....113 5.3.1) Περιγραφή πειράµατος...113 5.3.2) Επαλήθευση αποτελεσµάτων...114 5.3.3) Αποτελέσµατα µεθόδου χρήσης των Logs...114 5.3.4) Αποτελέσµατα µεθόδου χρήσης των triggers...115 5.3.5) Αποτελέσµατα µεθόδου χρήσης των materialized views(snapshots)...117 5.3.6) Συγκριτικά αποτελέσµατα, συµπεράσµατα και αποκλίσεις από τα θεωρητικά αναµενόµενα...120 ΚΕΦΑΛΑΙΟ 6 : ΕΠΙΛΟΓΟΣ...123 6.1) ΠΕΡΙΓΡΑΦΉ ΠΡΟΒΛΉΜΑΤΟΣ ΚΑΙ ΣΎΝΟΨΗ ΤΩΝ ΜΕΘΌ ΩΝ ΠΟΥ ΠΕΡΙΓΡΆΦΗΚΑΝ. ΣΥΜΠΕΡΆΣΜΑΤΑ...124 6.2) ΜΕΛΛΟΝΤΙΚΈΣ ΠΡΟΕΚΤΆΣΕΙΣ...125 ΚΕΦΑΛΑΙΟ 7 : ΒΙΒΛΙΟΓΡΑΦΙΑ...126 ΠΑΡΑΡΤΗΜΑΤΑ...128 Α) ΑΝΑΦΟΡΆ ΣΤΗΝ ORACLE...129 VERSION...129 Σύνδεση σε κάποιο instance της ORACLE...129 7

Ξεκινώντας, Κλείνοντας την ORACLE σε περιβάλλον LINUX...129 ΑRCHIVED MODE...130 SERVICE NAMES...130 BLOCKS ΕΝΤΟΛΩΝ ΚΑΙ ΗΜΙΟΥΡΓΙΑ ΚΑΙ ΕΚΤΕΛΕΣΗ ΣΥΝΑΡΤΗΣΕΩΝ ΜΕΣΑ ΑΠΟ ΤΟ ΠΕΡΙΒΑΛΛΟΝ ΤΗΣ ORACLE...130 DYNAMIC SQL...131 ΡΥΘΜΙΣΗ ODBC...131 Β) ΑΝΑΦΟΡΆ ΣΤΗΝ JAVA...132 VERSION...132 JDBC...132 COMPILE...132 ΕΧΕCUTION...133 C) ΠΕΡΙΓΡΑΦΉ ΚΛΆΣΕΩΝ JAVA...133 8

Κεφάλαιο 1 : ΕΙΣΑΓΩΓΗ 9

1.1) ΑΝΤΙΚΕΙΜΕΝΟ ΤΗΣ ΙΠΛΩΜΑΤΙΚΗΣ 1.1.1) Γενική περιγραφή Η παρούσα διπλωµατική εργασία ασχολείται µε το στάδιο ETL (extract, transform, load) στις αποθήκες δεδοµένων (data warehouses) και συγκεκριµένα µε αποδοτικούς αλγόριθµούς εξαγωγής δεδοµένων από σύστηµα OLTP (on line transaction processing) για τη µετέπειτα φόρτωσή τους στην αποθήκη. Αναζητούµε µεθόδους οι οποίες να εξάγουν πληροφορίες από το OLTP σύστηµα επιβάλλοντάς του µικρή επιβάρυνση, ενώ πρέπει παράλληλα, η φόρτωση αυτών στην αποθήκη δεδοµένων να µπορεί να γίνει σε εύλογο χρονικό διάστηµα. Οι αποθήκες δεδοµένων (µεγάλες βάσεις δεδοµένων, διαφορετικής συνήθως αρχιτεκτονικής από τα συνηθισµένα OLTP συστήµατα) έχουν κατακτήσει τελευταία ένα σηµαντικό τµήµα της έρευνας στο χώρο των βάσεων δεδοµένων και χρησιµοποιούνται πλέον σε ένα ευρύ φάσµα δραστηριοτήτων, σαν το decision supporting.για τη σωστή και οµαλή λειτουργία τους είναι απαραίτητο να ανανεώνονται τα δεδοµένα τους και να αντικαθίστανται µε τα καινούργια σε τακτά χρονικά διαστήµατα. Τα καινούργια αυτά δεδοµένα προέρχονται συνήθως από ένα ή περισσότερα µικρότερα OLTP συστήµατα (τα οποία αποτελούν τις πηγές πληροφοριών για αυτές) ή άλλου είδους εισόδους (πχ αρχεία COBOL για παλιότερα συστήµατα) και είναι προφανές πως δεν είναι στατικά, αλλά µεταβάλλονται µε την πάροδο του χρόνου, οπότε είναι και απαραίτητο να προωθούνται στην αποθήκη. Επιπλέον αφορούν, κυρίως, στατιστικά ή συγκεντρωτικά στοιχεία και πολύ σπάνια απαιτείται η αποστολή λεπτοµερειών. Οι παραπάνω ανανεώσεις, δηλ η εξαγωγή από τα OLTP συστήµατα των πληροφοριών και η φόρτωσή τους στην αποθήκη, γίνονται, σχεδόν πάντα, σε µαζική (batch) µορφή µε ειδικευµένα εργαλεία. Η εξαγωγή των δεδοµένων µπορεί να εκτελεστεί µε δύο διαφορετικές φιλοσοφίες. Σύµφωνα µε την πρώτη όλη η πληροφορία µεταφέρεται από τα OLTP συστήµατα στην αποθήκη, οδηγώντας έτσι σε έναν τεράστιο όγκο µεταφερόµενων δεδοµένων, ο οποίος στη συνέχεια θα πρέπει να φορτωθεί, θέτοντας off line τη δεύτερη για ένα σηµαντικό χρονικό διάστηµα. Σύµφωνα µε την άλλη φιλοσοφία, εντοπίζουµε µόνο τις αλλαγές στα στοιχεία της βάσης µας (δηλ τα inserts, updates & deletes που έχουν πραγµατοποιηθεί) και µεταφέρουµε µόνο αυτά. Προφανώς, σε αυτήν την περίπτωση, ο όγκος της µεταφερόµενης πληροφορίας µειώνεται αισθητά, µαζί µε τον χρόνο που απαιτείται να µείνει off line η αποθήκη. Είναι προφανές πως η τελευταία προοπτική είναι σαφώς προτιµότερη, αλλά και δυσκολότερη να υλοποιηθεί, αφού θα πρέπει σε κάθε περίπτωση να εντοπίζουµε τις αλλαγές στη βάση δεδοµένων του OLTP συστήµατος, πριν τις εξάγουµε. Στην παρούσα διπλωµατική υλοποιούµε και συγκρίνουµε µερικές από τις πιο δηµοφιλείς µεθόδους επαυξητικής εξαγωγής. Πιο συγκεκριµένα υλοποιούνται οι µέθοδος ανάλυσης των logs, η χρήση triggers και η χρήση snapshots (CRC & window algorithm). Σαν πλατφόρµα χρησιµοποιήθηκε το RDBMS ORACLE στην έκδοση 8.1.7. 1.1.2) Συνεισφορά Μέχρι τώρα, πολλοί αλγόριθµοι (σαν αυτούς που αναφέραµε προηγουµένως) έχουν προταθεί (τουλάχιστον σε θεωρητικό επίπεδο) και ακόµα λιγότεροι έχουν υλοποιηθεί. Μέσω της παρούσας διπλωµατικής δίνεται η ευκαιρία να υλοποιηθούν κάποιοι από αυτούς σε κοινή πλατφόρµα και να εκτελεστούν σε κοινή βάση δεδοµένων, ώστε να εξεταστεί κατά πόσο µπορούν να δώσουν απάντηση στο δύσκολο πρόβληµα του incremental extraction. Επιπλέον, µέσω των πειραµατικών 10

συγκρίσεων, δίνεται και µια πρώτη άποψη για την απόδοση των µεθόδων αυτών, σε διάφορα µεγέθη βάσης δεδοµένων (τουλάχιστον ως προς τη χρονική επιβάρυνση του συστήµατος, στο οποίο εκτελούνται). Έτσι η εργασία αυτή µπορεί να γίνει η απαρχή για µια εµπεριστατωµένη µελέτη του κάθε αλγορίθµου, ώστε να µελετηθούν οι καταστάσεις και τα συστήµατα, στα οποία αυτός αποδίδει καλύτερα. 1.2) ΟΡΓΑΝΩΣΗ ΤΟΥ ΤΟΜΟΥ Στο 1 ο κεφάλαιο αναφέρεται µε λίγα λόγια το αντικείµενο της διπλωµατικής και η οργάνωση του τόµου. Στο 2 ο κεφάλαιο της διπλωµατικής επιχειρείται µια εισαγωγή στην τεχνολογία των data warehouses, τα προβλήµατα που ανακύπτουν κατά τη λειτουργία τους, το incremental extraction και σε κάποιους αλγόριθµους που προσφέρουν λύσεις στο τελευταίο. Στο 3 ο κεφάλαιο αναλύονται οι παραπάνω αλγόριθµοι σε θεωρητική βάση, δίνοντας επιπλέον πληροφορίες και επεξηγήσεις για τις απαιτήσεις που αυτοί έχουν, καθώς και τυχόν παραλλαγές που µπορούν να προκύψουν. Σε κάθε περίπτωση αναφέρονται τα θεωρητικά πλεονεκτήµατα και µειονεκτήµατα, ενώ στο τέλος υπάρχει θεωρητική σύγκριση όλων. Στο 4 ο κεφάλαιο περιγράφεται η υλοποίηση του κάθε αλγόριθµου(µαζί µε τις παραλλαγές του). Στο 5 ο κεφάλαιο περιγράφεται το σχήµα της βάσης που χρησιµοποιήσαµε για την πραγµατοποίηση όλων των παραπάνω,ενώ ενσωµατώνεται και ένα παράδειγµα εκτέλεσης των µεθόδων που υλοποιήθηκαν. Στο 6 ο κεφάλαιο συγκρίνονται οι παραπάνω µέθοδοι πρακτικά (τουλάχιστον στον τοµέα του χρόνου εκτέλεσης και της χρονικής επιβάρυνση), χρησιµοποιώντας βάση δεδοµένων διαφόρων µεγεθών. Αναφέρονται τυχόν διαφορές από τα θεωρητικά αναµενόµενα και δικαιολογούνται. Στο 7 ο κεφάλαιο ακολουθεί ο επίλογος, όπου περιγράφονται µε λίγα λόγια, όλα όσα πραγµατοποιήθηκαν στη διπλωµατική και αναφέρονται και πιθανές µελλοντικές προεκτάσεις. Στο 8 ο κεφάλαιο δίνεται η βιβλιογραφία και γενικότερα οι πηγές οι οποίες προµήθευσαν τις απαραίτητες πληροφορίες για τη συγγραφή της διπλωµατικής. Τέλος υπάρχουν τα παραρτήµατα που παρέχουν χρήσιµες πληροφορίες για την ORACLE, την JAVA και γενικότερα οτιδήποτε χρησιµοποιήθηκε στην υλοποίηση των µεθόδων. 11

Κεφάλαιο 2 : ΠΕΡΙΓΡΑΦΗ ΠΡΟΒΛΗΜΑΤΟΣ 12

2.1) ΕΙΣΑΓΩΓΗ Είναι γεγονός ότι η τεχνολογία στις βάσεις δεδοµένων τις τελευταίες δεκαετίες αναπτύσσεται µε αλµατώδεις ρυθµούς δηµιουργώντας συστήµατα µεγαλύτερα και πολυπλοκότερα. Όλοι οι µεγάλοι οργανισµοί και επιχειρήσεις χρησιµοποιούν οργανωµένα συστήµατα διαχείρισης βάσεων δεδοµένων για την αποτελεσµατικότερη οργάνωση και επεξεργασία των δεδοµένων που προκύπτουν κατά τη λειτουργία τους. Οι οργανισµοί αυτοί χρησιµοποιούν δεκάδες (εκατοντάδες πολλές φορές) υποκαταστήµατα µέσω των οποίων οι πελάτες µπορούν να εκτελέσουν τις διάφορες συναλλαγές τους(κλασικό παράδειγµα είναι οι µεγάλες τράπεζες).τα κλασικά συστήµατα τα οποία χρησιµοποιούνται για τις συναλλαγές(oltp- On Line Transaction Processing) παρέχουν πολλές δυνατότητες για επεξεργασία µεγάλου αριθµού δοσοληψιών. Όµως δεν µπορούν να διαχειριστούν αποτελεσµατικά πολύ µεγάλο όγκο πληροφοριών πράγµα που θα αποτελεί µεγάλο µειονέκτηµα που θα εξελιχτεί σιγά-σιγά σε µεγαλύτερο µε την πάροδο του χρόνου (συνήθως το µειονέκτηµα αυτό οφείλεται στο σχεσιακό µοντέλο που χρησιµοποιείται από τα περισσότερα εµπορικά συστήµατα βάσεων δεδοµένων το οποίο είναι εξαιρετικά αποτελεσµατικό στην ελαχιστοποίηση της πλεονάζουσας πληροφορίας αλλά δεν είναι ιδιαίτερα αποδοτικό στον τοµέα της ταχύτητας εκτέλεσης των queries). Επιπλέον,σήµερα, γοργά αναπτύσσεται ο λεγόµενος τοµέας του decision support δηλ η αξιολόγηση προϊόντων και υπηρεσιών µε βάση τις προτιµήσεις των πελατών - καταναλωτών. Για να γίνει όµως µια τέτοια υπηρεσία υλοποιήσιµη θα πρέπει να υπάρχουν και τα αντίστοιχα εργαλεία τα οποία θα µπορούν να προσπελαύνουν µεγάλο όγκο πληροφοριών γρήγορα και αποτελεσµατικά.είναι προφανές ότι τα κλασικά OLTP συστήµατα δεν µπορούν να δώσουν λύση. Τη λύση καλούνται να δώσουν τα λεγόµενα συστήµατα OLAP (On Line Analytical Processing) και οι αποθήκες δεδοµένων (data warehouses). 2.2) Αποθήκες εδοµένων & Συστήµατα OLAP Μια αποθήκη δεδοµένων είναι,θα µπορούσαµε να πούµε,µια τεράστια βάση δεδοµένων η οποία προµηθεύεται πληροφορίες από πολλές µικρότερες DBs ενώ τα συστήµατα ΟLAP αναλαµβάνουν τη διαχείρισή της. Αποτελείται από ένα σύνολο τεχνολογιών και εργαλείων που µας βοηθούν στον τοµέα του decision support, µέσω της αποδοτικής εκµετάλλευσης των δεδοµένων που προκύπτουν κατά τη λειτουργία των βάσεων δεδοµένων που την υποστηρίζουν. Ουσιαστικά µια αποθήκη δεδοµένων συγκεντρώνει σε τακτά χρονικά διαστήµατα όλες τις πληροφορίες από ένα δίκτυο µικρότερων βάσεων δεδοµένων και στη συνέχεια τις χρησιµοποιεί για να µπορέσει να εξάγει χρήσιµα συµπεράσµατα που αφορούν την συµπεριφορά προϊόντων (ενδεχοµένως αυξήσεις στις πωλήσεις ή το αντίθετο) ή υπηρεσιών (ποσοστά χρήσης των υπηρεσιών κτλ) στην ευρύτερη αγορά. Η καταχώριση των πληροφοριών γίνεται σε τακτά χρονικά διαστήµατα και όχι σε οποιαδήποτε στιγµή όπως στα κλασικά OLTP συστήµατα. Αυτή είναι µια ουσιώδης διαφορά µεταξύ τους. Επίσης στις αποθήκες δεδοµένων συνήθως δεν µας χρειάζονται αναλυτικές πληροφορίες για το κάθε προϊόν ή υπηρεσία παρά µόνο όσες είναι απαραίτητες για την περαιτέρω στατιστική επεξεργασία. Επιπλέον διαφέρει συνήθως και το µέγεθος. Μπορούµε να φανταστούµε µια κλασική αποθήκη δεδοµένων µιας αλυσίδας super market, η οποία στο τέλος κάθε µήνα παίρνει τα δεδοµένα από όλα τα υποκαταστήµατα της αλυσίδας. Καταλαβαίνουµε λοιπόν ότι το µέγεθος της βάσης ξεπερνά τα κλασικά δεδοµένα και σε πολλές περιπτώσεις µπορεί να υπερβαίνει τα µερικά Tbytes. Αυτό δηµιουργεί και διάφορα προβλήµατα. 13

Ένα από αυτά είναι ότι για την αποτελεσµατική διαχείριση των πληροφοριών κατά την εκτέλεση των queries, δεν µπορούµε να χρησιµοποιήσουµε τα κλασικά µοντέλα (σχεσιακό και οντοτήτων-συσχετίσεων). Στην πραγµατικότητα,δεν µας ενδιαφέρει τόσο η εξοικονόµηση χώρου όσο η αποτελεσµατικότητα στην εκτέλεση των ερωτήσεων στη βάση. Έτσι πολλά νέα µοντέλα έχουν προταθεί, στα οποία τα δεδοµένα κατανέµονται είτε σε πολυδιάστατα σχήµατα (υπερκύβοι), είτε σε σχεσιακά διαφορετικής σχεδίασης (αστέρας,χιονονιφάδα), στα οποία τα δεδοµένα κατανέµονται σε πίνακες µε διαστάσεις. Ένα ακόµα πολύ µεγάλο πρόβληµα που αντιµετωπίζουµε στη σχεδίαση των συστηµάτων OLAP είναι η αποτελεσµατική ανανέωση των δεδοµένων ενός data warehouse. Προφανώς,όπως είπαµε, παρόλο που οι ανανεώσεις αυτές γίνονται συστηµατικά και σε τακτά χρονικά διαστήµατα,θα πρέπει σε ένα πολύ µικρό διάστηµα να βγουν όλα τα παλιά δεδοµένα από την αποθήκη δεδοµένων και να µπουν από την αρχή τα καινούργια,πράγµα φυσικά εξαιρετικά δύσκολο αφού ο όγκος της πληροφορίας είναι πολύ µεγάλος. Εξετάζονται λοιπόν τρόποι για την επιλεκτική εισαγωγή πληροφοριών στην αποθήκη δεδοµένων (συγκεκριµένα µόνο των δεδοµένων που έχουν υποστεί αλλαγή στα συστήµατα OLTP από την προηγούµενη καταχώριση των πληροφοριών). Το πρόβληµα όµως που ανακύπτει σε αυτήν την περίπτωση είναι, το πως θα συλλέγουµε από τα OLTP συστήµατα τις πληροφορίες που έχουν αλλάξει χωρίς όµως να δηµιουργήσουµε σοβαρή επιβάρυνση στο ίδιο το σύστηµα το οποίο είναι ήδη επιφορτισµένο µε την ικανοποίηση των διαφόρων ερωτοαποκρίσεων των χρηστών. Η τεχνική αυτή ονοµάζεται επαυξητική εξαγωγή (incremental extraction) και τρόπους υλοποίησής της θα αναλύσουµε στην συνέχεια. Υπάρχουν δύο διαφορετικές φιλοσοφίες σχεδίασης και χρήσης ενός συστήµατος διαχείρισης βάσεων δεδοµένων. Τα OLTP (on line transaction processing) αντιπροσωπεύουν τα κλασικά συστήµατα που χρησιµοποιούµε στις συνηθισµένες µας δοσοληψίες, ενώ τα OLAP (on line analytical processing) χρησιµοποιούνται για την ανάλυση των δεδοµένων µε σκοπό την ανάλυση της γενικότερης συµπεριφοράς των προϊόντων ή των υπηρεσιών που τα πρώτα αντιπροσωπεύουν. Έτσι τα OLTP συστήµατα σχεδιάζονται µε γνώµονα τη βελτιστοποίηση του transaction throughput, δηλ την ικανοποίηση όσο το δυνατών περισσοτέρων δοσοληψιών µε κάθε είδους πράξεις πάνω στα δεδοµένα (insert,update,select) που επηρεάζουν µικρό αριθµό tuples κάθε φορά. Επιπλέον προσπαθούµε να µειώσουµε τον όγκο των δεδοµένων µε όσο το δυνατόν λιγότερη επαναλαµβανόµενη πληροφορία. Τα OLAP από την άλλη πλευρά σχεδιάζονται µε τρόπο που να βελτιστοποιείται το query throughput και το response time. Μας ενδιαφέρει δηλαδή να µπορούµε να εκτελούµε όσο το δυνατόν πιο αποδοτικά πολύπλοκα queries που ενδεχοµένως να διαβάζουν και όλα τα δεδοµένα της βάσης µας (που το µέγεθος τους είναι πολύ µεγαλύτερο, συνήθως, από αυτό ενός τυπικού OLTP συστήµατος) και µε τη µικρότερη δυνατή καθυστέρηση. Κάθε query (σε συντριπτικό ποσοστό select) συνήθως επηρεάζει µεγάλο αριθµό από tuples, ενώ η είσοδος µπορεί να είναι από πίνακες οργανωµένου συστήµατος βάσης δεδοµένων έως raw αρχεία που περιέχουν δεδοµένα αποθηκευµένα σε άτακτη µορφή. Επιπλέον τις περισσότερες φορές δεν χρειαζόµαστε αναλυτικές πληροφορίες, αλλά κυρίως συγκεντρωτικά αποτελέσµατα. Απόρροια των παραπάνω είναι η διαφορετική αρχιτεκτονική που ακολουθούµε κατά το σχεδιασµό ενός OLAP συστήµατος. ύο είναι οι επικρατέστερες. Είτε κωδικοποιούµε τα δεδοµένα µας µε πολυδιάστατο τρόπο (MOLAP 14

multidimensional OLAP) είτε µε σχεσιακό,που να µιµείται όµως τον πολυδιάστατο (ROLAP relational OLAP). Πριν προχωρήσουµε παρακάτω πρέπει να ορίσουµε τις διαστάσεις στα συστήµατα OLAP. Τα δεδοµένα µας µπορούµε να τα θεωρήσουµε µεταβλητές οι οποίες µεταβάλλονται µε βάση κάποιους παράγοντες (όπως ο χρόνος). Οι παράγοντες αυτοί αποτελούν τις διαστάσεις σε ένα OLAP σύστηµα. Μπορούµε να έχουµε ιεραρχία διαστάσεων όπως πχ στο χρόνο: έτος->µήνας->ηµέρα. Στα ROLAP στηρίζουµε τη βάση µας σε σχεσιακό σύστηµα διαχείρισής της. Για τη πρόσβαση σε αυτά χρησιµοποιούµε SQL µε κάποιες επεκτάσεις Οι βασικές αρχιτεκτονικές σχεδίασης που χρησιµοποιούνται είναι τα σχήµατα αστέρα και χιονονιφάδας. Στον αστέρα έχουµε έναν κεντρικό πίνακα (fact table) στον οποίο κρατάµε τις τιµές των δεδοµένων µας και τους πίνακες των διαστάσεων που περιέχουν τις τιµές αυτών. Μεταξύ τους συνδέονται µέσω foreign keys. Μια επέκταση του αστέρα αποτελεί η χιονονιφάδα που προκύπτει από αυτόν µετά από κανονικοποίηση των πινάκων των διαστάσεων. Το πλεονέκτηµα της είναι πως διαχειρίζεται καλύτερα την ιεραρχία των τελευταίων. Μπορούµε να δούµε καλύτερα τις δύο αρχιτεκτονικές στα σχήµατα που ακολουθούν: Αρχιτεκτονική Αστέρα. 15

Αρχιτεκτονική Χιονονιφάδας. Στα MOLAP χρησιµοποιούνται ευρέως οι υπερκύβοι.. Τα δεδοµένα αποθηκεύονται σε ν-διάστατους πίνακες, όπου κάθε διάσταση έχει µια ιεραρχία επιπέδων. Οι τιµές που περιέχονται στους υπερκύβους αντιστοιχούν στις στήλες των σχεσιακών πινάκων και είναι οι τιµές των δεδοµένων µας. Συνήθεις πράξεις σε υπερκύβους είναι: Rollup : Ανεβαίνουµε ένα βήµα στην ιεραρχία µιας διάστασης. Ουσιαστικά παίρνουµε συγκεντρωτικά αποτελέσµατα για τα κατώτερα επίπεδα της ιεραρχίας. Drilldown : Είναι το αντίθετο της παραπάνω διαδικασίας. Εδώ παίρνουµε αναλυτικότερα δεδοµένα. Slice & Dice : Επιλέγουµε τα δεδοµένα µέσα σε κάποια όρια τιµών µιας ή περισσοτέρων διαστάσεων. Pivoting : Αποτελεί αλλαγή της διάταξης των διαστάσεων σε ένα υπερκύβο. Μπορούµε να δούµε ένα τυπικό παράδειγµα υπερκύβου στο παρακάτω σχήµα: 16

Αρχιτεκτονική υπερκύβου. Στη συνέχεια ακολουθεί ένα γενικό πλάνο της λειτουργίας µιας αποθήκης δεδοµένων: Μετάδοση δεδοµένων στην αποθήκη δεδοµένων. 17

Παρατηρούµε πως τα δεδοµένα,µέσα από µια διαδικασία (διαδικασία ETL),µεταφέρονται στο data warehouse. Στη συνέχεια προωθούνται είτε στα data marts (κρατούν υποσύνολα των δεδοµένων της αποθήκης για πιο εξειδικευµένους σκοπούς) είτε µέσω ειδικών εργαλείων χρησιµοποιούνται από τους αναλυτές κτλ. To σηµαντικότερο στάδιο σε αυτήν τη διαδικασία είναι το ETL (extract, transform, load) όπου και πραγµατοποιούνται όλες οι απαραίτητες διαδικασίες, ώστε τα δεδοµένα να είναι έτοιµα να φορτωθούν στην αποθήκη. Χωρίζεται στα παρακάτω µέρη: Εξαγωγή δεδοµένων από τις πηγές. Συνήθως πραγµατοποιείται µέσω πυλών (gateways) όπως το ODBC, Information Builders EDA/SQL, Oracle Open Connect, Sybase Enterprise Connect, Informix Enterprise Gateway. Μετατροπή και ολοκλήρωση των δεδοµένων. Σκοπός είναι η διόρθωση τους από λάθη και η µετατροπή τους (data migration, data scrubbing, data auditing) ώστε να υπακούν σε κάποιο νοητό καθολικό σχήµα ώστε να µπορούν να φορτωθούν στην αποθήκη. Φόρτωση των δεδοµένων στο data warehouse. Τελικό στάδιο αποτελεί η φόρτωση στην αποθήκη. Συνήθως χρησιµοποιούνται batch load utilities (δηλ εργαλεία µαζικής εισαγωγής) αφού πρώτα ελεγχθούν οι απαραίτητοι περιορισµοί ακεραιότητας της αποθήκης πάνω στα δεδοµένα αυτά. Οι µέθοδοι που θα παρουσιάσουµε στη συνέχεια, ουσιαστικά αναφέρονται στο στάδιο ETL και µάλιστα κυρίως κατά το extract,transform. 2.3) Επαυξητική εξαγωγή(incremental Extraction) Ουσιαστικά αυτό που µας ενδιαφέρει να επιτύχουµε είναι να µπορέσουµε µε κάποιο τρόπο να ξεχωρίσουµε τα δεδοµένα (σε κάθε OLTP σύστηµα) που έχουν αλλάξει από τη τελευταία χρονική στιγµή που τα τοποθετήσαµε στο data warehouse. Για να είµαστε σε θέση να κάνουµε κάτι τέτοιο έχουν προταθεί οι παρακάτω τρεις τρόποι: 1. Με χρήση του log που κρατά η ίδια η βάση των δεδοµένων για σκοπούς recovery 2. Με χρήση triggers (timestamps ή χωρίς) 3. Και τέλος µε χρήση snapshots ( δηλ δυναµικών όψεων-materialized views των πινάκων της βάσης), χρησιµοποιώντας είτε CRC codes, είτε window algorithm. Για την ανάλυση και την υλοποίηση των παραπάνω µεθόδων θα χρησιµοποιήσουµε την πλατφόρµα της Qracle (που είναι και η πιο συχνά χρησιµοποιούµενη για την υλοποίηση µεγάλων συστηµάτων βάσεων δεδοµένων).οι παραπάνω µέθοδοι προσπαθούν (µε διαφορετική λογική η κάθε µία) να επιλύσουν το δύσκολο αυτό πρόβληµα. Όλες πάντως µε κάποιο τρόπο διακρίνουν τις αλλαγές στη βάση δεδοµένων σε κάθε OLTP σύστηµα και µε βάση αυτές εκτελούν στη συνέχεια τις µετατροπές στο OLAP σύστηµα. Πρέπει να τονίσουµε πως η ανάλυση µας κυρίως αφορά την πλευρά των OLTP συστηµάτων, αφού εκεί παράγονται τα δεδοµένα και κατά συνέπεια εκεί εκτελούνται οι περισσότερες διαδικασίες. Για την αποθήκη δεδοµένων και την οργάνωσή της δεν υπάρχουν ιδιαίτερες απαιτήσεις. Μόνο στις µεθόδους χρήσης των logs και των triggers, απαιτείται στο data warehouse να αποθηκεύονται και τα rowids των tuples που εισάγονται αφού χρησιµοποιούνται σαν κλειδιά από αυτές για τα δεδοµένα. Ακολουθεί η ανάλυση της µεθόδου χρήσης των logs, στη συνέχεια των triggers και τέλος των snapshots. 18

Kεφάλαιο 3 : ΘΕΩΡΗΤΙΚΗ ΠΕΡΙΓΡΑΦΗ ΑΛΓΟΡΙΘΜΩΝ 19

3.1) Εισαγωγή Στο κεφάλαιο αυτό αναλύουµε θεωρητικά τους αλγορίθµους, τους οποίους αναφέραµε. Για κάθε έναν, αναφέρουµε, αναλυτικά, τις έννοιες και τα αντικείµενα που σχετίζονται µε αυτόν και περιγράφουµε τα βήµατα (σε θεωρητικό υπόβαθρο) που ακολουθούµε για να επιτύχουµε επαυξητική εξαγωγή από ένα σχεσιακό σύστηµα βάσεων δεδοµένων. Ακολουθούν κάποια θεωρητικά πλεονεκτήµατα και µειονεκτήµατα που περιµένουµε από τη µέθοδο που τον υλοποιεί. Tο κεφάλαιο τελειώνει µε τη θεωρητική σύγκριση όλων των αλγορίθµων, όπου αναφέρονται οι τοµείς, στους οποίους περιµένουµε, ο κάθε ένας, να υπερέχει. 3.2) Θεωρητική περιγραφή της µεθόδου ανάλυσης των logs 3.2.1) Περιγραφή των αρχείων log και χρησιµότητα τους Η πρώτη µέθοδος που θα παρουσιαστεί έχει να κάνει µε την προσπέλαση πληροφοριών κατευθείαν µέσα από τα logs ενός σχεσιακού συστήµατος βάσεων δεδοµένων. Όπως είναι γνωστό, κάθε µεγάλο και πλήρως οργανωµένο σχεσιακό σύστηµα διαχείρισης βάσεων δεδοµένων,παράλληλα µε τις λοιπές λειτουργίες του, κρατά και κάποιο είδος logs δηλ αρχεία τα οποία έχουν σκοπό να βοηθήσουν στη διατήρηση της ιστορίας των δεδοµένων της βάσης και µε αυτό τον τρόπο να διευρύνουν την ασφάλεια που παρέχεται γι αυτά. Συνήθως υπάρχει κάποια ξεχωριστή διεργασία (µία ή και περισσότερες),που εκτελείται παράλληλα µε τις διεργασίες των δοσοληψιών που διαχειρίζεται το σύστηµα, και η οποία αναλαµβάνει σε κάθε αλλαγή στη βάση,να εκτελείται κάποια αντίστοιχη ενέργεια ενηµέρωσης των αντίστοιχων αρχείων logs. Τις περισσότερες φορές χρησιµοποιείται η τεχνική του write ahead log δηλ πρώτα ενηµερώνεται ο µηχανισµός καταγραφής και µετά γίνεται η αλλαγή στη βάση. Όταν λέµε αλλαγή στη βάση δεν εννοούµε µόνο τα συνήθη insert, update, delete αλλά και κάθε άλλου είδους αλλαγές όπως αλλαγές στο σχήµα της βάσης (δηµιουργία πινάκων, όψεων, αλλαγή σε κάποιο ήδη υπάρχον αντικείµενο, ενέργειες administrator πάνω στην ίδια τη βάση κτλ). Η σηµαντικότερη λειτουργία των logs έχει να κάνει µε την ασφάλεια των δεδοµένων µέσω της αναίρεσης-επανάληψης δοσοληψιών σε περίπτωση που δηµιουργηθεί κάποιο πρόβληµα κατά την διεκπεραίωση κάποιας από αυτές. Συγκεκριµένα σε κάποια τέτοια περίπτωση όλες οι αλλαγές τις οποίες έχει προκαλέσει κάποια διεργασία στα δεδοµένα της βάσης αναιρούνται µέχρι ένα προκαθορισµένο σηµείο checkpoint (το σηµείο συνέπειας της βάσης όπου όλα τα δεδοµένα έχουν αποθηκευτεί στα δευτερεύοντα αποθηκευτικά µέσα της βάσης και θεωρούνται πλέον ασφαλή) και εκτελούνται από την αρχή µέχρι το σηµείο που δηµιουργήθηκε το πρόβληµα µε βάση τις αποθηκευµένες τιµές που βρίσκονται στα logs, µε αποτέλεσµα η βάση να επανέρχεται σε κάποιο συνεπές σηµείο. Τα logs όµως δεν είναι προορισµένα µόνο για την ασφάλεια της βάσης αλλά και για τον έλεγχο των δεδοµένων που µπήκαν στη βάση µας και τη χρονική στιγµή που αυτό συνέβη, ενώ µπορούµε να αντλήσουµε επιπλέον πληροφορίες όπως ποιος χρήστης προσπέλασε τη βάση σε κάποια δεδοµένη χρονική στιγµή ή χρονική περίοδο, τι αλλαγές έχουν γίνει στο σχήµα της βάσης, να πάρουµε µια εποπτική εικόνα της βάσης και των στοιχείων µέσα στο χρόνο (πολύ χρήσιµο στο χώρο της ανάλυσης αποφάσεων και της βελτιστοποίησης της απόδοσης του συστήµατος). 20

Γενικότερα προµηθεύουν τον administrator µε πολύτιµα εργαλεία που βοηθούν στον έλεγχο και τη διαχείριση της βάσης. Είναι προφανές από τα παραπάνω ότι τα logs κρατούν πολλών ειδών πληροφορίες και προφανώς αυτές είναι διαφορετικές από ένα σύστηµα διαχείρισης βάσεων δεδοµένων σε κάποιο άλλο. Όµως είναι κάποιες πληροφορίες που συνήθως υπάρχουν σε κάθε σύστηµα διαχείρισης βάσεων δεδοµένων : Ο κωδικός της δοσοληψίας που εκτέλεσε την αλλαγή στη βάση Ο κωδικός του αντικειµένου στο οποίο εκτελέστηκε η αλλαγή Ο κωδικός του tuple στο οποίο εκτελέστηκε η αλλαγή (µπορούν να είναι τα primary keys του αντικειµένου στο οποίο ανήκει το tuple ή κάποιο εσωτερικός κωδικός που δίνει το ίδιο το σύστηµα για δική του διευκόλυνση) Η πράξη που επιτελέστηκε Η πράξη που την αναιρεί Η νέα τιµή του tuple Η παλιά τιµή του tuple Η χρονική στιγµή που εκτελέστηκε η αλλαγή. Μπορεί να µην αντιστοιχεί σε πραγµατικό χρόνο αλλά σε κάποια εσωτερικά αναπαράσταση του συστήµατος που οδηγεί σε κάποια χρονική διάκριση των δεδοµένων Όλος ο µηχανισµός συνήθως υλοποιείται σε δύο φάσεις. Καταρχήν όλες οι πληροφορίες που αφορούν το logging καταγράφονται στην κύρια µνήµη του συστήµατος και στη συνέχεια (σε ορισµένα χρονικά σηµεία) καταγράφονται σε ειδικά αρχεία της βάσης στον δευτερεύοντα αποθηκευτικό χώρο της βάσης. 3.2.2) Εκµετάλευση των logs για την απόσπαση πληροφοριών σχετικών µε τις αλλαγές που έχουν γίνει στη βάση-incremental extraction Προφανώς τα δεδοµένα που αποθηκεύονται στα logs είναι αρκετά για να αποσπάσουµε πληροφορίες για τις αλλαγές στη βάση µας. Όλες οι πληροφορίες που χρειαζόµαστε υπάρχουν στα logs δηλαδή οι τιµές των δεδοµένων, η πράξη που επιτελέστηκε καθώς και η χρονική στιγµή της. Άρα για την περίπτωση µας που θέλουµε να επιτύχουµε incremental extraction µπορούµε πολύ εύκολα (µε τη χρήση κατάλληλου εργαλείου το οποίο πρέπει να µπορεί να διαβάζει τα log files της βάσης) να εξάγουµε όλα τα insert, update, delete που έγιναν σε συγκεκριµένα αντικείµενα (συνήθως πίνακες) πέρα από κάποια χρονική στιγµή που θα αντιστοιχεί στην τελευταία χρονικά στιγµή κατά την οποία πραγµατοποιήθηκε ενηµέρωση του data warehouse από το OLTP στο οποίο αναφερόµαστε. Κατά συνέπεια αυτό που χρειαζόµαστε είναι να κρατάµε σε κάποιον πίνακα κάποιο στοιχείο το οποίο θα µας βοηθά να εντοπίζουµε τις αλλαγές χρονικά που έχουν πραγµατοποιηθεί πάνω στη βάση δηλ να κρατάµε την χρονική στιγµή (timestamp) κατά την οποία πραγµατοποιήθηκε η τελευταία ανανέωση του data warehouse. Έτσι σε κάθε incremental extraction θα διαβάζουµε από τον παραπάνω πίνακα την πληροφορία για το τελευταίο incremental extraction και µε βάση αυτή θα αρχίσουµε την επεξεργασία των logs. Για κάθε αντικείµενο που µας ενδιαφέρει (δηλ για τους πίνακες που συµµετέχουν στη διαδικασία-µην ξεχνάµε ότι στα logs περιέχονται πληροφορίες για όλα τα αντικείµενα της βάσης ακόµα και γι αυτά που διαχειρίζεται το ίδιο το σύστηµα) εξάγουµε σε βοηθητικούς πίνακες τα tuples για τα οποία έχει εκτελεστεί κάποιο insert, update ή delete. Συγκεκριµένα στους πίνακες που θα εξάγουµε θα καταγράφονται τόσο η τιµή του tuple, όσο και το timestamp και η ενέργεια που 21

εκτελέστηκε για να διευκολυνθεί αργότερα η διαδικασία εισαγωγής τους κατά το ETL του data warehouse. Τα δεδοµένα που θα πάρουµε µε αυτόν τον τρόπο µπορούµε πλέον (µε τη βοήθεια κατάλληλου εργαλείου) να τα εξάγουµε σε αρχεία και να τα στείλουµε στην αποθήκη δεδοµένων. Εκεί θα εκτελεστεί η αντίστροφη διαδικασία,όπου διαβάζοντας τις παραπάνω πληροφορίες θα µπορούµε να δούµε ποιες αλλαγές έχουν πραγµατοποιηθεί. Προφανώς στο τέλος της διαδικασίας θα αλλάζουµε το timestamp ώστε να αντιστοιχεί σε αυτό της καινούργιας ανανέωσης. Η διαδικασία γίνεται ελαφρώς πιο πολύπλοκη αν µέσα στα logs δεν κρατάµε τις τιµές των tuples παρά µόνο τα κλειδιά τους (ή κάποιο κωδικό τους). Σε αυτήν την περίπτωση κατά τη στιγµή που διαβάζουµε τις πληροφορίες από τα logs αντί να εξάγουµε δεδοµένα κατευθείαν στους πίνακες εξαγωγής κάνουµε πρώτα join πάνω στα κλειδιά που διαβάζουµε από τα logs και τους πίνακες της βάσης ώστε να πάρουµε τα δεδοµένα. 3.2.3) Log mining µέσα από την Oracle Χρησιµοποιώντας σαν αναφορά την ORACLE µπορούµε να περιγράψουµε καλύτερα τη µέθοδο. Το εργαλείο που διατίθεται µαζί της (από την έκδοση 8 και πάνω και µόνο µε την Server) είναι ο Logminer. Είναι ένα σχεσιακό εργαλείο το οποίο µπορεί να διαβάζει τα logs της ORACLE και µας επιτρέπει να κάνουµε ερωτήσεις SQL πάνω σε αυτά. Μπορεί να διαβάσει τόσο online redo logs (δηλ logs τα οποία βρίσκονται στην µνήµη του συστήµατος) όσο και archived logs (δηλ logs τα οποία έχουν αποθηκευτεί στη δευτερεύουσα µνήµη του συστήµατος -σκληρός δίσκος- σε binary µορφή). Ο Lοgminer διαβάζει τα logs και αποθηκεύει τα αποτελέσµατα σε ένα view (που έχει δηµιουργηθεί γι αυτό ακριβώς το σκοπό). Στο view αυτό µπορούµε στη συνέχεια να εκτελέσουµε select queries για να αποκτήσουµε τις πληροφορίες που θέλουµε. Άρα γενικά σε κάθε ανανέωση του data warehouse: ιαβάζουµε την παλιά τιµή του timestamp που έχουµε αποθηκεύσει σε κάποιον ειδικό γι αυτόν τον σκοπό πίνακα Εκτελούµε τον logminer στο OLTP ιαβάζουµε από το αντίστοιχο view (V$LOGMNR_CONTENTS) µόνο εκείνες τις πληροφορίες(τα κλειδιά) για τους πίνακες που έχουµε στο repository και που έχουν timestamp µεγαλύτερο από αυτό που διαβάσαµε στο πρώτο βήµα και ενέργειες insert,update ή delete. Κάνουµε join τα κλειδιά που διαβάζουµε από το view µε τους πίνακες για να πάρουµε τα δεδοµένα που µας ενδιαφέρουν. Οι διαδικασίες αυτές λαµβάνουν χώρα στο OLTP. Αποθηκεύουµε τα παραπάνω αποτελέσµατα σε πίνακες (ξεχωριστά για κάθε πίνακα τα insert,update,delete) εξαγωγής. Χρησιµοποιούµε το export utility της ORACLE για να εξάγουµε τα δεδοµένα των παραπάνω πινάκων σε αρχείο το οποίο θα µεταφερθεί στο data warehouse. Εκεί κάνουµε import τα δεδοµένα και τα αναλύουµε. Σταµατάµε τον Logminer και ανανεώνουµε την τιµή του timestamp που υποδηλώνει την τελευταία ανανέωση Σβήνουµε τα δεδοµένα από τους πίνακες εξαγωγής. Τα βήµατα αυτά περιγράφονται πιο αναλυτικά στην υλοποίηση της µεθόδου. 22

3.2.4) Θεωρητικά πλεονεκτήµατα της µεθόδου Η µέθοδος εκµετάλλευσης των ήδη υπαρχόντων logs εκ πρώτης όψεως φαίνεται ελκυστική. Προφανώς δεν επιβαρύνει καθόλου το σύστηµα κατά τη διάρκεια της κανονικής του λειτουργίας. Τα logs ούτως ή άλλως δηµιουργούνται. Άρα στα µεσοδιαστήµατα λειτουργίας του OLTP (δηλ µεταξύ δύο ανανεώσεων του data warehouse) έχουµε µηδενική επιβάρυνση. Όλη η επιβάρυνση σε επεξεργαστική ισχύ γίνεται µόνο κατά τη διάρκεια του incremental extraction, δηλ κατά την επεξεργασία των logs και την απόκτηση των αποτελεσµάτων στους πίνακες εξαγωγής. Μπορούµε να µειώσουµε και το κόστος αυτής της διεργασίας µεταφέροντας τα logs στο data warehouse ή κάποιον ενδιάµεσο σταθµό για την επεξεργασία τους (οπότε θα σταλούν πίσω στο OLTP µόνο τα κλειδιά για την αποστολή των δεδοµένων στο DW) αλλά θα πρέπει κατά τη διάρκεια αυτής, οι πίνακες µας στο OLTP να µην επηρεαστούν γιατί αλλιώς µπορεί να γίνει κάποια αλλαγή σε αυτούς χωρίς να την εντοπίσουµε. Επιπλέον δεν χρειαζόµαστε πολύ περισσότερο χώρο από την αρχική µας βάση παρά µόνο αυτόν που καταλαµβάνουν οι πίνακες εξαγωγής. Γενικά περιµένουµε από τη συγκεκριµένη µέθοδο πολύ καλή απόδοση τόσο στον τοµέα της κατανάλωσης επεξεργαστικής ισχύος από το OLTP (περισσότερο) όσο και στον τοµέα της κατανάλωσης επιπλέον χώρου (λιγότερο). Τέλος ο όγκος της πληροφορίας που πρόκειται να µεταφερθεί στην αποθήκη δεδοµένων είναι όσο το δυνατόν λιγότερος (τηρουµένων των αναλογιών φυσικά), αφού στέλνονται µόνο οι αλλαγές, αφού τις έχουµε πρώτα εντοπίσει. 3.2.5) Θεωρητικά µειονεκτήµατα της µεθόδου Ένα από τα µειονεκτήµατα της µεθόδου έγκειται ακριβώς στην χρήση του εργαλείου Logminer και στους εγγενείς περιορισµούς του. Το εργαλείο αυτό λειτουργεί µόνο για βάσεις ORACLE 8i και πάνω και πρέπει να εκτελεστεί σε βάση µε το ίδιο database character set µε αυτή στην οποία δηµιουργήθηκαν τα logs µε το ίδιο hardware. Επιπλέον δεν υποστηρίζονται δοµές όπως: index-organized tables, clustered tables/indexes, non scalar data types, chained rows. Επιπλέον µέσα από τον logminer µπορούµε να διαβάσουµε µόνο τα rowids των αλλαγµένων tuples και όχι τα κλειδιά τους και έτσι εξαρτόµαστε αποκλειστικά από αυτά. Επιπλέον µειονέκτηµα µπορεί να θεωρηθεί και η µειωµένη δυνατότητα να επέµβουµε άµεσα και να διαβάσουµε το log,παρά µόνο στηριζόµαστε σε κάποιο ήδη έτοιµο πακέτο ενώ ακόµα και για την εκτέλεση του εργαλείου απαιτείται ο χρήστης να έχει administrator privileges. 3.3) Θεωρητική προσέγγιση της µεθόδου συνεχούς παρακολούθησης της βάσης-triggers 3.3.1) Γενική περιγραφή της µεθόδου Σε αυτή τη δεύτερη µέθοδο, σκοπός µας είναι η επίβλεψη των ίδιων των λειτουργιών του συστήµατος διαχείρισης της βάσης µας µε απώτερο στόχο να κρατάµε πληροφορίες για το είδος και το χρόνο των ενεργειών που πραγµατοποιούνται κάθε στιγµή στο σύστηµα µας (τουλάχιστον για αυτές που µας ενδιαφέρουν). Έχοντας αυτή τη δυνατότητα µπορούµε να πραγµατοποιήσουµε incremental extraction στο σύστηµά µας. Είναι προφανές ότι η δυνατότητα για τέτοια εποπτεία των δεδοµένων και των ενεργειών που επιβάλλονται σε αυτά, πρέπει να παρέχεται από το ίδιο το σύστηµα διαχείρισης βάσεων δεδοµένων που χρησιµοποιούµε. Έτσι µπορούµε ανά πάσα στιγµή, παρατηρώντας κάποια αλλαγή 23

(insert, update, delete) πάνω στα αντικείµενα που χρησιµοποιούµε, να εκτελέσουµε τις κατάλληλες ενέργειες που θα µας βοηθήσουν αργότερα (κατά τη χρονική στιγµή της ανανέωσης του data warehouse) να αναγνωρίσουµε αυτές τις διαφοροποίησεις. Συγκεκριµένα µας ενδιαφέρει να µπορούµε να βρούµε ποια tuples έχουν αλλάξει και πότε άλλαξαν (και συγκεκριµένα αν αυτή η αλλαγή εκτελέστηκε χρονικά ανάµεσα στο προηγούµενο incremental extraction και σε αυτό που θα γίνει στη συνέχεια). Για να αναγνωρίσουµε τα tuples που έχουν αλλάξει µπορούµε είτε να τα αποθηκεύουµε ολόκληρα, είτε να αποθηκεύουµε τα κλειδιά (ή κάποιο κωδικό για αυτά), οπότε στη συνέχεια µπορούµε από αυτά να βρούµε το υπόλοιπο tuple. Σε κάθε περίπτωση χρειαζόµαστε κάποια διεργασία η οποία θα επιβλέπει τα transactions στη βάση µας και θα εκτελεί τις προαναφερθείσες ενέργειες. Υπάρχουν διάφορες στρατηγικές που µπορούµε να ακολουθήσουµε, µε βάση την παραπάνω τεχνική, για να επιτύχουµε το στόχο µας του incremental extraction. Σε κάθε περίπτωση χρησιµοποιούµε πίνακες αντίγραφα οι οποίοι κρατούν τα δεδοµένα που έχουν αλλάξει. Από αυτούς στο τέλος θα εξαχθούν τα δεδοµένα που έχουν αλλάξει. Σύµφωνα µε την πρώτη µέθοδο, σε κάθε αλλαγή των πινάκων µας, τα δεδοµένα (ολόκληρα τα tuples) µεταφέρονται στον πίνακα αντίγραφο. Έτσι τη χρονική στιγµή του incremental extraction µεταφέρουµε τις πληροφορίες των πινάκων-αντίγραφα στην αποθήκη δεδοµένων. Εδώ µπορούµε για την αναγνώριση των αλλαγµένων tuples να χρησιµοποιήσουµε οποιαδήποτε από τις προαναφερόµενες τεχνικές, δηλ είτε να αποθηκεύουµε ολόκληρα τα tuples είτε να αποθηκεύουµε µόνο τα πρωτεύοντα κλειδιά (οπότε και οι πίνακες αντίγραφα πλέον, χρειάζεται να περιέχουν πεδία µόνο για την αποθήκευση αυτών). Σε κάθε περίπτωση η λογική παραµένει η ίδια, αλλάζει µόνο ο όγκος των δεδοµένων και η πολυπλοκότητα της µεθόδου κατά το incremental extraction. Στο τέλος σβήνουµε τα δεδοµένα που έχουµε αποθηκεύσει στους πίνακες αντίγραφα. Στη δεύτερη µέθοδο χρησιµοποιούµε τα λεγόµενα timestamps. Λέγοντας timestamp εννοούµε κάποιο χαρακτηριστικό στα δεδοµένα µας, το οποίο να µας δίνει κάποια πληροφορία για τη χρονική στιγµή που πραγµατοποιήθηκε η συναλλαγή και η αλλαγή στα δεδοµένα µας. Τα timestamps µπορούν να είναι οτιδήποτε, από την ηµεροµήνια του συστήµατος έως κάποιο ενδεικτικό νούµερο που να αυξάνει µε κάθε incremental extraction. Οπότε σε κάθε αλλαγή των δεδοµένων µας, µεταφέρουµε είτε ολόκληρα τα tuples στον πίνακα αντίγραφο µαζί µε το timestamp, είτε µόνο τα πρωτέυοντα κλειδιά των tuples µαζί και πάλι µε το timestamp. Το τελευταίο φυσικά το χρειαζόµαστε για τη χρονική πληροφορία που µας παρέχει. Γενικά η λογική στις µεθόδους µε τα triggers είναι να επιβλέπουµε το σύστηµα µας και σε κάθε αλλαγή των δεδοµένων µας να καταγράφουµε τις αλλαγές σε κάποιους πίνακες αντίγραφα µε τρόπο που να µπορούµε να αναγνωρίσουµε πότε αυτές συνέβησαν. Στη συγκεκριµένη διπλωµατική έχουν υλοποιηθεί και οι δύο µέθοδοι και ακολουθούν... 3.3.2) TRIGGERS στην Oracle Είπαµε και προηγουµένως ότι για να µπορέσουµε να υλοποιήσουµε µεθόδους σαν τις παραπάνω σε ένα σχεσιακό σύστηµα διαχείρισης βάσεων δεδοµένων, πρέπει να έχουµε στη διάθεση µας µηχανισµούς που θα µας επιτρέπουν την εποπτεία των λειτουργιών και των δοσοληψιών που λαµβάνουν χώρα πάνω στα δεδοµένα µας. Στην ORACLE ο µηχανισµός αυτός ονοµάζεται triggers. Tα triggers είναι 24

ουσιαστικά stored procedures τα οποία όµως ενεργοποιούνται µε βάση κάποια αλλαγή στη βάση (δεν τα καλεί ο χρήστης). Οπότε για να υλοποιήσουµε τις παραπάνω µεθόδους θα µπορούσαµε να δηµιουργήσουµε triggers τα οποία δουλεύοντας στο παρασκήνιο θα φροντίζουν σε κάθε insert, update, delete να ενηµερώνουν τους πίνακες αντίγραφα µε τα δεδοµένα αλλαγής ή/και τα timestamps. 3.3.3) Θεωρητική περιγραφή πρώτης εκδοχής Χρησιµοποιώντας ορολογία της ORACLE µπορούµε πλέον να εξετάσουµε θεωρητικά την πρώτη µέθοδο. Πρέπει να επισηµάνουµε πως στη συγκεκριµένη θεώρηση θα χρησιµοποιήσουµε βοηθητικούς πίνακες ακριβή αντίγραφα των αρχικών και κατά συνέπεια θα µεταφέρουµε σε αυτούς ολόκληρα τα tuples και όχι µόνο τα κλειδιά. Τα βήµατα που ακολουθουµε για την προετοιµασία της µεθόδου είναι: ηµιουργούµε για κάθε πίνακα που θέλουµε να συµµετάσχει στο incremental extraction τρεις πίνακες. Ο πρώτος κρατά τα tuples που προέκυψαν από κάποιο insert. Ο δεύτερος κρατά αυτά από τα updates ενώ ο τρίτος των delete. Οι δύο πρώτοι ορίζονται όπως ακριβώς ο πίνακας από τον οποίο δέχονται δεδοµένα (χωρίς ίσως τους περιορισµούς ακεραιότητας διότι πχ αν κάνουµε δύο αλλαγές στην ίδιο γραµµή ενός πίνακα, τότε στον πίνακα που εισάγονται τα update θα είχαµε δύο γραµµές µε το ίδιο κλειδί-µία για κάθε update). Ο τρίτος χρειάζεται να περιέχει µόνο τα πρωτεύοντα κλειδιά του πίνακα. ηµιουργούµε τα απαραίτητα triggers. Για κάθε πίνακα χρειαζόµαστε τρία από αυτά. Το πρώτο φροντίζει να µεταφέρει τα tuples που εισάγονται στον πίνακα και στον βοηθητικό πίνακα που κρατάµε τα insert, το δεύτερο κάνει το ίδιο αλλά για τον βοηθητικό που κρατάµε τα update, ενώ το τελευταίο χρησιµοποιείται για τα rows που γίνονται delete και µεταφέρει τα κλειδιά των tuples στον βοηθητικό πίνακα για τα delete. Σε κάθε ανανέωση του data warehouse: ιαβάζουµε τις τιµές του από τους βοηθητικούς πίνακες (εκεί που κρατάµε τα insert, update, delete) και χρησιµοποιώντας το εργαλείο export της ORACLE µεταφέρουµε τα δεδοµένα αυτά σε αρχείο για τη µεταφορά στην αποθήκη δεδοµένων. Μεταφέρουµε τις πληροφορίες στο data warehouse όπου και τις επεξεργαζόµαστε. Σβήνουµε τα δεδοµένα από τους βοηθητικούς πίνακες για να προετοιµαστούµε για την επόµενη ανανέωση. Αυτό είναι απαραίτητο ώστε να µην χρειαστούµε κάποιο timestamp για την επόµενη ανανέωση του data warehouse. 3.3.4) Θεωρητική περιγραφή δεύτερης εκδοχής-timestamps Και η δεύτερη µέθοδος ουσιαστικά στηρίζεται στην ίδια λογική µε αυτή της πρώτη µεθόδου. Και εδώ έχουµε τρεις πίνακες για κάθε έναν της βάσης µας. Στη συγκεκριµένη περίπτωση κρατάµε (µαζί µε το timestamp) µόνο τα πρωτεύοντα κλειδιά(συγκεκριµένα τα rowids) των tuples που έχουν αλλάξει ή διαγραφεί. Οπότε στο τέλος για να πάρουµε τα rows που έχουν αλλάξει θα πρέπει να πραγµατοποιήσουµε join µεταξύ των κλειδιών που έχουµε στους βοηθητικούς πίνακες και των δεδοµένων που υπάρχουν στον κύριο πίνακα. Τα βήµατα που ακολουθούµε για την προετοιµασία της µεθόδου είναι: ηµιουργούµε για κάθε πίνακα της βάσης µας που συµµετέχει στο incremental extraction δύο πίνακες. Ο πρώτος (έστω Χ) κρατά κατά τα 25

µεσοδιαστήµατα µεταξύ δύο συνεχόµενων ανανεώσεων του data warehouse τα κλειδιά και τα timestamps των γραµµών του πίνακα που γίνονται insert ή update. Ο δεύτερος (πίνακες εξαγωγής) είναι αυτός από τον οποίο θα πάρουµε τα δεδοµένα προς εξαγωγή κατά την ανανέωση της αποθήκης δεδοµένων και ο οποίος ενηµερώνεται µε τα αλλαγµένα δεδοµένα λίγο πριν τα εξάγουµε. Τα δεδοµένα που δέχεται αυτός προέρχονται από το join του προηγούµενου Χ και του βασικού µας πίνακα για το τελευταίο timestamp. Επιπλέον δηµιουργούµε έναν πίνακα ο οποίος θα είναι υπεύθυνος για τα delete που γίνονται στους πίνακες που παρακολουθούµε. Είναι εννιαίος για όλα τα αντικείµενά µας ( οπότε εκτός από τα πρωτεύοντα κλειδιά και το timestamp κρατάµε και το όνοµα του αντικειµένου). Φυσικά θα µπορούσαµε να δηµιουργήσουµε έναν πίνακα που θα κρατά τα delete για κάθε πίνακα που συµµετέχει στο incremental extraction. Προφανώς τα δεδοµένα που θα εξαχθούν από αυτόν θα είναι αυτά µε το τελευταίο timestamp, όπως και προηγούµενως. Τώρα βέβαια δεν χρειαζόµαστε κάποιο join διότι ούτως ή άλλως για τα delete χρειαζόµαστε µόνο τα κλειδιά. Κατασκευάζουµε βοηθητικούς πίνακες για να κρατάµε το τελευταίο timestamp για να µπορούµε σε κάθε περίπτωση να αναγνωρίζουµε στους παραπάνω πίνακες ποιες είναι οι τελευταίες αλλαγές. Φυσικά δηµιουργούµε τα κατάλληλα triggers. ιαφέρουν από αυτά της προηγούµενης µεθόδου στο ότι εδώ δεν αποθηκεύουν ολόκληρα rows αλλά µόνο τα κλειδιά τους (µαζί µε το timestamp). Επιπλέον εδώ το trigger για το update εισάγει τιµές τόσο στον πίνακα που έχουµε για τα insert/update όσο και στον πίνακα που έχουµε για τα delete (άλλωστε ένα update είναι στην πραγµατικότητα ένα delete ακολουθούµενο από ένα insert). Στην προηγούµενη µέθοδο είχαµε ξεχωριστό πίνακα για τα update. Τα βήµατα που ακολουθούµε κατά το incremental extraction είναι: ιαβάζουµε την τελευταία τιµή του timestamp από το σχετικό πίνακα δηλ την τιµή που είχαµε από την τελευταία ανανέωση του data warehouse. H τιµή αυτή θα χρησιµοποιηθεί για να προσδιορίσουµε τις καινούργιες αλλαγές. Κρατάται σταθερή κατά το διάστηµα µεταξύ δύο συνεχόµενων ανανεώσεων της αποθήκης δεδοµένων και µεταβάλλεται µόνο κατά την ανανέωση της τελευταίας. Εκτελούµε join µεταξύ των κλειδιών που έχουµε κρατήσει στους αντίστοιχους πίνακες και των βασικών πινάκων της βάσης µας. Στη συνέχεια επιλέγουµε τα δεδοµένα εκείνα που έχουν timestamp που συµπίπτει µε αυτό που διαβάσαµε από το σχετικό πίνακα στο προηγούµενο βήµα. Οι πληροφορίες αυτές εισάγονται στη συνέχεια στους πίνακες εξαγωγής. Χρησιµοποιούµε το εργαλείο export της ORACLE για να εξάγουµε τις πληροφορίες που έχουµε στους παραπάνω πίνακες εξαγωγής και µάλιστα τα δεδοµένα µόνο µε το παραπάνω timestamp. Στο τέλος ανανεώνουµε την τιµή του timestamp µε αυτή του τελευταίου incremental extraction ώστε να είµαστε έτοιµοι για το επόµενο. Πρέπει να συµπληρώσουµε ότι σαν timestamp µπορούµε να χρησιµοποιήσουµε: 1. Την ηµεροµηνία του συστήµατος. 2. Μια <<συντµηµένη>> έκδοση της ηµεροµηνίας του συστήµατος (για παράδειγµα να µην κρατάµε τις µέρες, αλλά µόνο βδοµάδες ή µήνες. Άλλωστε η επαυξητική εξαγωγή, ακριβώς εξαιτίας του κόστους, δεν πραγµατοποιείται συχνά. Φυσικά αυτό δεν είναι πανάκεια αλλά εξαρτάται από την περίπτωση. Το κέρδος µας είναι ο λιγότερος χώρος 26

και η µειωµένη πολυπλοκότητα στους υπολογισµούς σε σχέση µε την προηγούµενη εκδοχή. 3. Χρησιµοποιούµε κάποιον αριθµό (ακέραιο) ο οποίος θα µας δηλώνει την χρονική διαδοχή των αλλαγών στη βάση µας. Ο αριθµός αυτός προφανώς αλλάζει σε κάθε ανανέωση της αποθήκης δεδοµένων µας. Τα δεδοµένα µεταξύ δύο διαδοχικών τέτοιων ανανεώσεων έχουν το ίδιο τέτοιο νούµερο σαν timestamp. H συγκεκριµένη εκδοχή υιοθετήθηκε στην παραπάνω µέθοδο γιατί προφανώς προσφέρει τη µέγιστη δυνατή απλότητα στις συγκρίσεις και τις πράξεις (όταν ερευνούµε για τις τελευταίες αλλαγές στα δεδοµένα µας) και επιπλέον καταλαµβάνει και το µικρότερο χώρο από τα δύο παραπάνω. Για την υλοποίηση της παραγωγής ακεραίων χρησιµοποιούµε τη δοµή sequence. 4. Και µια παραλλαγή της προηγούµενης εκδοχής είναι αυτή στην οποία αντί το νούµερο να παραµένει σταθερό στα µεσοδιαστήµατα δύο επαυξητικών εξαγωγών, αντίθετα αυξάνει. Έτσι κρατάµε τις δύο τιµές (αυτή της προηγούµενης ανανέωσης της αποθήκης δεδοµένων µας και φυσικά την τελευταία που προκύπτει από το µεγαλύτερο νούµερο που έχουµε σε timestamp στα δεδοµένα µας) και εξάγουµε τα δεδοµένα που το timestamp τους βρίσκεται ανάµεσα στις δύο αυτές τιµές. Στη δεύτερη αυτή µέθοδο αυτή προφανώς δεν σβήνουµε τα δεδοµένα από τους βοηθητικούς πίνακες γιατί µπορούµε να διαχωρίζουµε τα δεδοµένα τους. Μια άλλη παραλαγή της µεθόδου µε τα timestamps είναι να επέµβουµε στους ίδιους τους πίνακες της βάσης µας. Μπορούµε να τους τροποποιήσουµε ώστε να αποκτήσουν µια καινούργια στήλη, η οποία θα περιέχει το timestamp (δεν θα χρησιµοποιούµε ξεχωριστό πίνακα γι αυτό δηλαδή). Σε αυτήν την περίπτωση θα µπορούσαµε να διαλέξουµε κατευθείαν τα δεδοµένα από τους πίνακες προσέχοντας µόνο να έχουν timestamp ίσο µε αυτό που θα διαβάσουµε από το σχετικό πίνακα (όπως περιγράψαµε στο πρώτο βήµα). Το πρόβληµα βέβαια σε αυτή την περίπτωση είναι ότι αλλάζοντας τον ορισµό των πινάκων της βάσης, δυσχεραίνει για τους χρήστες αυτής, η χρησιµοποίησή της. Για παράδειγµα θα πρέπει να αλλάξουν τα insert ώστε να λαµβάνουν υπόψη τους το καινούργιο πεδίο. Κατά συνέπεια σαν µέθοδος προτείνεται µόνο όταν υπάρχει διαφάνεια στον τελικό χρήστη, πχ όταν υπάρχει κάποιο εξωτερικό interface για τη διαχείριση της βάσης. 3.3.5) Θεωρητικά πλεονεκτήµατα των µεθόδων µε τα TRIGGERS Το µεγάλο πλεονέκτηµα το οποίο µας δίνουν τα triggers είναι ο απόλυτος έλεγχος που αυτά µας προσφέρουν στην όλη διαδικασία. Επιπλέον είναι µια µέθοδος πολύ απλή στη σύλληψη και πολύ απλή στην υλοποίηση. Έχει επίσης το πλεονέκτηµα ότι σαν µέθοδος έχει χρησιµοποιηθεί από ένα µεγάλο µέρος σχεδιαστών data warehouses, κάτι που πείθει για την ευχρηστία και την αποτελεσµατικότητά της. Σε πιο τεχνικό τοµέα περιµένουµε τη µέθοδο να έχει πολύ µικρό overhead σε επεξεργαστική ισχύ κατά την περίοδο της επαυξητικής εξαγωγής. Τα δεδοµένα είναι ήδη σε εκµεταλεύσιµη µορφή εκείνη τη χρονική στιγµή. Μένουν µόνο µερικά join για να πάρουµε τις πληροφορίες που θα εξάγουµε. Επιπλέον από άποψη χώρου σαν µέθοδος/µέθοδοι δεν είναι ιδιαίτερα απαιτητική (συγκρινόµενη πάντα µε τις υπόλοιπες). Τα βασικά επιπλέον αντικείµενα που χρειάζεται να δηµιουργηθούν για την υποστήριξή της είναι σχεδόν τα ίδια µε αυτά της µεθόδου ανάλυσης των logs. 27

Τέλος η µεταφερόµενη,στην αποθήκη δεδοµένων, πληροφορία είναι και πάλι όσο το δυνατόν λιγότερη, αφού και εδώ στέλνονται µόνο οι αλλαγές. Γενικά σαν µέθοδος/µέθοδοι περιµένουµε να έχει <<µέτρια>> απόδοση, 3.3.6) Θεωρητικά µειονεκτήµατα των µεθόδων µε τα TRIGGERS Το βασικό µειονέκτηµα της µεθόδου έχει να κάνει µε την επιπλέον επιβάρυνση που επιβάλλουν τα triggers κατά τη κανονική λειτουργία του συστήµατος. Προφανώς τα triggers σαν διαδικασίες, όπως και να έχουν υλοποιηθεί, απαιτούν επεξεργαστική ισχύ από το σύστηµα για τη λειτουργία τους. Η επιβάρυνση αυτή µπορεί να γίνει πολύ σηµαντική όσο ο αριθµός των πινάκων που παρακολουθούµε µεγαλώνει και κατά συνέπεια αυξάνεται και ο αριθµός των triggers που χρησιµοποιούµε. Ας µην ξεχνάµε ότι µε προσθήκη ενός επιπλέον πίνακα στην λίστα αυτών που συµµετέχουν στον incremental extraction, προσθέτουµε τρία ακόµα triggers στο σύστηµα για να διαχειρίζεται. Ακόµα από άποψη χώρου, το σύστηµα προφανώς επιβαρύνεται (και στις δύο παραπάνω εκδοχές που παρουσιάσαµε) αφού για να εφαρµοστούν αυτές πρέπει να δηµιουργηθούν επιπλέον πίνακες. 3.3.7) Σύγκριση µεταξύ των δύο διαφορετικών εκδοχών: triggers & timestamps Όπως αναφέραµε και παραπάνω οι δύο αυτές εκδοχές-µέθοδοι δεν διαφέρουν τόσο πολύ ούτε στην φιλοσοφία λειτουργίας ούτε και στην υλοποίηση. Υπάρχουν όµως λεπτοµέρειες που δηµιουργούν διαφορές στη λειτουργία τους και στην απόδοσή τους. Στην πρώτη εκδοχή, όπως είδαµε, σε κάθε αλλαγή, µεταφέρονται ολόκληρα tuples στους βοηθητικούς πίνακες. Στη δεύτερη µεταφέρουµε εκτός από το timestamp, µόνο τα πρωτεύοντα κλειδιά. Αυτό προφανώς είναι πλεονέκτηµα για την δεύτερη εκδοχή αφού ο όγκος των µεταφερόµενων πληροφοριών κατά την φυσιολογική λειτουργία τους συστήµατος είναι σαφώς µικρότερος, κάτι που καταλήγει και σε µικρότερο overhead του συστήµατος OLTP. Φυσικά το γεγονός αυτό δηµιουργεί και τα µειονεκτήµατά του. Συγκεκριµένα επειδή στην πρώτη εκδοχή, τα δεδοµένα είναι ήδη έτοιµα (έτσι µεταφέρονται από τα triggers) στους πίνακες εξαγωγής, κατά το incremental extraction το µόνο που χρειάζεται να κάνουµε είναι να εξάγουµε τις πληροφορίες µας χωρίς καµιά περαιτέρω επεξεργασία. Από την άλλη πλευρά στη δεύτερη εκδοχή τη χρονική στιγµή που πραγµατοποιούµε την επαυξητική εξαγωγή τα µόνο δεδοµένα που έχουµε <<έτοιµα>> είναι τα πρωτεύοντα κλειδιά των tuples στα οποία έχει πραγµατοποιηθεί insert, update, delete. Έτσι αναγκαζόµαστε να εκτελέσουµε join µεταξύ των πινάκων που περιέχουν τα κλειδιά αυτά µαζί µε τα timestamps, µε τους βασικούς πίνακες της βάσης µας, τόσο πάνω στα κλειδιά αυτά, όσο και πάνω στο column που κρατά το timestamp, ώστε να επιλέξουµε, όπως είπαµε, τις τελευταίες αλλαγές για να τις εισάγουµε στους πίνακες εξαγωγής. Αυτά τα join,είναι προφανές, ότι εισάγουν overhead στο σύστηµά µας. Βέβαια στην πρώτη µέθοδο σβήνουµε τους βοηθητικούς πίνακές µας µε το τέλος της ανανέωσης του data warehouse, κάτι που πάλι µε τη σειρά του εισάγει overhead στη διαδικασία, ενώ στη δεύτερη, όπου κρατάµε και τις παλιές αλλαγές, χωρίς να σβήνουµε τίποτα, καταλήγουµε σε σπατάλη χώρου. Συνοψίζοντας θα µπορούσαµε να πούµε πως περιµένουµε από την πρώτη εκδοχή να εισάγει µεγαλύτερη επιβάρυνση στο σύστηµά µας κατά της διάρκεια της κανονικής του λειτουργίας (δηλαδή στο µεσοδιάστηµα δύο συνεχόµενων ανανεώσεων της αποθήκης δεδοµένων µας), ενώ κατά της διάρκεια του incremental extraction, η δεύτερη µέθοδος, κατά πάσα πιθανότητα, θα επιβαρύνει περισσότερο 28