ΕΘΝΙΚΟ ΜΕΤΣΟΒΙΟ ΠΟΛΥΤΕΧΝΕΙΟ ΣΧΟΛΗ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΤΕΧΝΟΛΟΓΙΑΣ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΥΠΟΛΟΓΙΣΤΩΝ ΠΡΟΧΩΡΗΜΕΝΑ ΘΕΜΑΤΑ ΒΑΣΕΩΝ Ε ΟΜΕΝΩΝ Τ. Σελλής ΦΘΙΝΟΠΩΡΟ 2005 Λύση ΑΣΚΗΣΗΣ #3 ΕΡΩΤΗΜΑ 1: ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΕΙΣ ΒΑΣΕΙΣ Ε ΟΜΕΝΩΝ Σας ζητάνε να φτιάξετε ένα καινούργιο αντικειµενοστρεφές σύστηµα διαχ. Βάσεων εδοµένων που υποστηρίζει κληρονοµικότητα. Για να βγάλετε κάτι γρήγορα αγοράζετε ένα σχεσιακό σύστηµα και σχεδιάζετε να υλοποιήσετε ένα αντικειµενοστρεφές µοντέλο πάνω από αυτό, το ΣΒΕΛΤΟ. Για παράδειγµα, ένα σχήµα στο ΣΒΕΛΤΟ θα ήταν: create class EMP (ename: string, age: int, sal: float) with key (ename); create class MarriedEMP (spouse: string) inherits from EMP; Περιγράψτε δύο εναλλακτικές προσεγγίσεις για να χειριστείτε κληρονοµικότητα στο σχεσιακό σύστηµα. ώστε σε λεπτοµέρεια την προσέγγισή σας δείχνοντας πώς οι κλάσεις EMP και MarriedEMP θα αντιστοιχίζονταν σε σχέσεις για κάθε προσέγγιση (αν θέλετε χρησιµοποιείστε και παραδείγµατα). Εξηγείστε τα προτερήµατα και τα µειονεκτήµατα της κάθε προσέγγισης όσον αφορά στην επεξεργασία ερωτήσεων. Θεωρείστε ότι κάποιες ερωτήσεις θα είναι πάνω σε όλα τα στιγµιότυπα µιας κλάσης (π.χ. της MarriedEMP), ενώ άλλες θα είναι πάνω σε όλα τα στιγµιότυπα µιας κλάσης και των υποκλάσεών της (π.χ. όλα τα αντικείµενα της EMP και της MarriedEMP). Λύση ύο εναλλακτικές προσεγγίσεις για τον χειρισµό της κληρονοµικότητας σε ένα σχεσιακό σύστηµα είναι οι ακόλουθες: Πρώτη Προσέγγιση: ηµιουργούµε Μία σχέση για τον υπερτύπο. Μία σχέση για κάθε υποτύπο, µε το πρωτεύον κλειδί του υπερτύπου και τα δικά του γνωρίσµατα (µόνο). Στο παράδειγµα της εκφώνησης θα έχουµε: CREATE TABLE EMP ( ename age sal VARCHAR(300) NOT NULL PRIMARY KEY, INTEGER NOT NULL, FLOAT NOT NULL) CREATE TABLE MarriedEMP ( ename VARCHAR(300) NOT NULL PRIMARY KEY, spouse VARCHAR(300) NOT NULL) 1
εύτερη Προσέγγιση: ηµιουργούµε Μία σχέση για τον υπερτύπο. Μία σχέση για κάθε υποτύπο, µε επανάληψη όλων των πεδίων του υπερτύπου στον υποτύπο. Στο παράδειγµα της εκφώνησης θα έχουµε: CREATE TABLE EMP ( ename age sal VARCHAR(300) NOT NULL PRIMARY KEY, INTEGER NOT NULL, FLOAT NOT NULL) CREATE TABLE MarriedEMP ( ename age sal spouse VARCHAR(300) NOT NULL PRIMARY KEY, INTEGER NOT NULL, FLOAT NOT NULL, VARCHAR(300) NOT NULL) Στην πρώτη προσέγγιση οι πίνακες είναι σε κανονικοποιηµένη µορφή µε αποτέλεσµα το µέγεθος των πινάκων που αποθηκεύονται στη βάση δεδοµένων να είναι το ελάχιστο. Αντίθετα, στη δεύτερη προσέγγιση έχουµε πλήρη επανάληψη όλων των πεδίων των υπερτύπων σε κάθε υποτύπο, το οποίο οδηγεί σε αύξηση του µεγέθους των πινάκων που αντιστοιχούν στους υποτύπους. Το πρόβληµα αυτό γίνεται ακόµα πιο αισθητό σε περιπτώσεις ιεραρχιών µε περισσότερα από δύο επίπεδα. Επιπλέον, η επανάληψη των πεδίων των υπερτύπων σε κάθε υποτύπο δηµιουργεί ένα πρόσθετο κόστος κατά την εκτέλεση λειτουργιών ενηµέρωσης (insert/update). Αυτό οφείλεται στην επανάληψη της ίδιας πληροφορίας ανάµεσα στους πίνακες για τους υποτύπους και τον πίνακα για τον υπερτύπο, οπότε για να διατηρηθεί η βάση δεδοµένων σε συνεπή κατάσταση πρέπει η ενηµέρωση να γίνει σε όλους τους πίνακες. Από την άλλη, εάν οι ερωτήσεις που γίνονται είναι κυρίως σε συγκεκριµένα στιγµιότυπα µίας κλάσης (π.χ. MarriedEMP) τότε η δεύτερη προσέγγιση οδηγεί σε πιο γρήγορη αποτίµησή τους, καθώς αντιστοιχούν σε απλά SELECT ερωτήµατα στον αντίστοιχο πίνακα της σχεσιακής βάσης δεδοµένων. Αντίθετα, στην πρώτη προσέγγιση πρέπει να γίνει join ανάµεσα στη σχέση που αντιστοιχεί στον υποτύπο και τη σχέση που αντιστοιχεί στον υπερτύπο ώστε να ανασυνθέσουµε τον υποτύπο. Π.χ. η ερώτηση για την ηλικία και το όνοµα των παντρεµένων υπαλλήλων της εταιρείας µε µισθό πάνω από 1500 Ευρώ αντιστοιχεί στα ερωτήµατα: Πρώτη Προσέγγιση: SELECT EMP.age, MarriedEMP.spouse FROM EMP, MarriedEMP WHERE MarriedEMP.ename = EMP.ename AND EMP.sal > 1500 εύτερη Προσέγγιση: SELECT age, spouse FROM MarriedEMP WHERE sal > 1500 Είναι φανερό ότι τέτοιου είδους ερωτήσεις είναι αρκετά πιο ακριβές όταν ακολουθούµε την πρώτη προσέγγιση. 2
Παρατήρηση: Εάν ο υπερτύπος είναι abstract, δηλαδή δεν υπάρχουν αντικείµενα που να αντιστοιχούν σε αυτόν και ορίζεται µόνο µε στόχο τον ορισµό των υποτύπων του, τότε δεν χρειάζεται να οριστεί πίνακας για τον υπερτύπο. Οι αναφορές στον υπερτύπο µπορούν να αντιµετωπιστούν µέσω του ορισµού µίας όψης (view), η οποία να αντιστοιχεί στην ένωση των πινάκων των υποτύπων του και προβολή των πεδίων που ορίζονται στον υπερτύπο. Εξαίρεση αποτελεί η περίπτωση όπου χρειάζεται να οριστεί σε κάποιον άλλο τύπο (πίνακα) εξωτερικό κλειδί (ref) το οποίο να αναφέρεται στον υπερτύπο. ΕΡΩΤΗΜΑ 2: ΑΠΟΘΗΚΕΣ Ε ΟΜΕΝΩΝ Έστω µια διεθνής εταιρεία που διατηρεί αποθήκη και επεξεργάζεται παραγγελίες για ανταλλακτικά. Για κάθε ανταλλακτικό (PART) υπάρχει ένας προµηθευτής (SUPPLIER). Κάθε πελάτης (CUSTOMER) κάνει παραγγελίες (ORDER). Κάθε παραγγελία αναλύεται σε υποπαραγγελίες (LINEITEM), κάθε µία εκ των οποίων αντιστοιχεί σε κάποιο προϊόν (π.χ., µια παραγγελία µπορεί να αποτελείται από τις υποπαραγγελίες (i) 10 µολύβια Η2 και (ii) 20 γόµες µολυβιών). (α) Είναι το παρακάτω σχήµα ένα σχήµα αστέρα (star schema)? Αν όχι, διορθώστε το ώστε να είναι (διόρθωση = πρόσθεση/διαγραφή/αλλαγή κάποιων πεδίων/πινάκων). είξτε τα εξωτερικά κλειδιά στους πίνακες. (β) Σε οποιαδήποτε από τις δύο περιπτώσεις, εντοπίστε (i) τις διαστάσεις, (ii) την ιεραρχία των επιπέδων τους, (iii) τα µέτρα όπως προκύπτουν από το εν λόγω σχήµα. PART PARTSUPP LINEITEM ORDER MFGR AVAILQTY LINENUMBER ORDERSTATUS BRAND SUPPLYCOST QUANTITY TOTALPRICE TYPE EXTENDEDPRICE ORDERDATE SIZE DISCOUNT ORDERPRIORITY CONTAINER RETAILPRICE SUPPLIER ADDRESS CUSTOMER ADDRESS MKTSEGMENT TAX RETURNFLAG LINESTATUS SHIPDATE COMMITDATE RECEIPTDATE SHIPINSTRUCT SHIPMODE CLERK SHIPPRIORITY NATION REGION Λύση (α) Το σχήµα δεν είναι ένα σχήµα αστέρα. Μια πιθανή λύση στο πρόβληµα σχεδίασης της συγκεκριµένης αποθήκης δεδοµένων προκύπτει εάν θεωρήσουµε ως πίνακα συµβάντων (fact table) τον πίνακα LINEITEM µε τις υποπαραγγελίες. Κάθε υποπαραγγελία εξαρτάται από την αντίστοιχη παραγγελία στην οποία ανήκει, τον πελάτη που την έκανε και το προϊόν το οποίο παραγγέλθηκε. Επιπλέον, εφόσον για κάθε ανταλλακτικό υπάρχει ένας (και µόνο ένας) προµηθευτής, οι πίνακες PART, PARTSUPP και SUPPLIER αντιστοιχούν σε µία µοναδική διάσταση (από την οποία εξαρτάται η πληροφορία στον πίνακα συµβάντων). Με βάση τα παραπάνω, ένα σχήµα αστέρα θα µπορούσε να είναι το ακόλουθο: 3
PART_SUPP_DIM MFGR SIZE CONTAINER RETAILPRICE BRAND TYPE NATION REGION NATION REGION AVAILQTY SUPPLYCOST PURTSUP LINEITEM LINENUMBER QUANTITY EXTENDEDPRICE DISCOUNT TAX RETURNFLAG LINESTATUS SHIPDATE COMMITDATE RECEIPTDATE SHIPINSTRUCT SHIPMODE CUSTOMER MKTSEGMENT NATION REGION NATION REGION ORDER ORDERSTATUS TOTALPRICE ORDERDATE ORDERPRIORITY CLERK SHIPPRIORITY Μια κάπως διαφορετική λύση θα προέκυπτε εάν δεν υπήρχε ο περιορισµός ότι για κάθε ανταλλακτικό υπάρχει ένας (και µόνο ένας) προµηθευτής, οπότε η σχέση µεταξύ ανταλλακτικών και προµηθευτών θα ήταν Ν:Ν (π.χ. διαφορετικός supplier για το ίδιο part ανά περιοχή ή γενικότερα πολλοί supplier για το ίδιο part µε διαφορετικά κόστη). Σε αυτή την περίπτωση και ο πίνακας PART_SUPP είναι πίνακας συµβάντων και µοιράζεται µε τον άλλο πίνακα συµβάντων LINEITEM τη διάσταση PART. Η συγκεκριµένη επιλογή έχει νόηµα σε περίπτωση που ενδιαφερόµαστε σε ερωτήσεις ανάλυσης της µορφής: ποια είναι η συνολική διαθέσιµη ποσότητα για ένα συγκεκριµένο ανταλλακτικό ανά περιοχή (όπου θεωρούµε ότι κάθε supplier προµηθεύει µόνο την περιοχή του) ή ποιο είναι το µέσο supply cost για τα ανταλλακτικά ενός συγκεκριµένου τύπου στην Γαλλία. Με βάση αυτή τη διαφορετική θεώρηση των δεδοµένων, ένα πιθανό σχήµα αστέρα θα µπορούσε να είναι το ακόλουθο: 4
PARTSUPP PSKEY AVAILQTY SUPPLYCOST PART MFGR BRAND TYPE SIZE CONTAINER RETAILPRICE SUPPLIER NATION REGION NATION REGION LINEITEM LINENUMBER QUANTITY EXTENDEDPRICE DISCOUNT TAX RETURNFLAG LINESTATUS SHIPDATE COMMITDATE RECEIPTDATE SHIPINSTRUCT SHIPMODE CUSTOMER MKTSEGMENT NATION REGION NATION REGION ORDER ORDERSTATUS TOTALPRICE ORDERDATE ORDERPRIORITY CLERK SHIPPRIORITY Τέλος, ένα κάπως διαφορετικό σχήµα θα προέκυπτε θεωρώντας τις διάφορες ηµεροµηνίες στον πίνακα LINEITEM (SHIPDATE, COMMITDATE, RECEIPTDATE) ως αναφορές σε έναν επιπλέον πίνακα (διάσταση) DATE. (β) (i) Οι διαστάσεις στα προηγούµενα σχήµατα αστέρα είναι οι ακόλουθες: CUSTOMER ORDER PART_SUPP_DIM (στο πρώτο σχήµα) PART (στο δεύτερο σχήµα) SUPPLIER (στο δεύτερο σχήµα) (ii) Οι αντίστοιχες ιεραρχίες είναι: Για τα CUSTOMER και SUPPLIER: Region Region Nation Nation CustKey SuppKey Στο ORDER δεν ορίζεται κάποια εµφανής ιεραρχία: Μπορούµε να θεωρήσουµε ότι αποτελείται από ένα µοναδικό επίπεδο, το οποίο αποτελείται από το OrderKey. 5
Για το PART: Brand Type PartKey Τέλος, για το PART_SUPP_DIM µπορούµε να έχουµε τόσο τις δύο ιεραρχίες που έχουµε και στο PART όσο και την ιεραρχία που προκύπτει από το SUPPLIER (εφόσον υπάρχει ένα προς ένα σχέση µεταξύ προϊόντων και προµηθευτών): SuppRegion Brand Type SuppNation PartKey (iii) Εάν θεωρήσουµε ως πίνακα συµβάντων (fact table) τον πίνακα LINEITEM µε τις υποπαραγγελίες, τότε τα µέτρα είναι: o Quantity o ExtendedPrice o Discount o Tax Εάν θεωρήσουµε και τον επιπλέον πίνακα συµβάντων PARTSUPP, έχουµε και τα επιπλέον µέτρα: o AvailQTY o SupplyCost 6