Lecture 21: Functional Dependencies and Normalization

Transcript

1 Department of Computer Science University of Cyprus EPL342 Databases Lecture 21: Functional Dependencies and Normalization Informal Design Guidelines (Chapter 10.1, Elmasri-Navathe 5ED) ιδάσκων: Παναγιώτης Ανδρέου

2 Περιεχόµενο ιάλεξης Εισαγωγή στην Κανονικοποιήση (Normalization) Άτυπες κατευθύνσεις για Σχεδιασµό µιας Καλής Βάσης 1) Σηµασιολογία (Semantics) των Γνωρισµάτων Σχέσεων 2) Πλεονάζουσες (Redundant) Πληροφορίες σε Πλειάδες και Ανωµαλίες Ενηµερώσεων 3) Τιµές NULL σε πλειάδες 4) ηµιουργία Πλασµατικών Πλειάδων (Spurious Tuples) Επόµενες ιαλέξεις Συναρτησιακές Εξαρτήσεις (Functional Dependencies): To µαθηµατικό υπόβαθρο της Κανονικοποιήσης. Κανονικοποιήση µε Χρήση Συναρτησιακών Εξαρτήσεων: 1NF, 2NF, 3NF και BCNF, κτλ. 21-2

3 Εισαγωγή στην Κανονικοποιήση (Normalization) Η Σχεδίαση του Σχεσιακού Σχήµατος µιας βάσης δεδοµένων µέχρι στιγµής γινόταν βάσει της κοινής λογικής του σχεδιαστή και όχι βάσει αυστηρών κανόνων. Τα παραγόµενα σχήµατα µπορούσαν να κριθούν υποκειµενικάως προς την Χρηστότητα (Goodness) τους αλλά όχι αντικειµενικά. Παρόλο που αναφερθήκαµε στο παρελθόν σε κάποιες γενικές οδηγίες χαρακτηρισµού της Χρηστότητας (Goodness)ενός Σχεσιακού Σχήµατος, π.χ., Να ΜΗΝ υπάρχει επανάληψη πληροφορίας Να ΜΗΝ υπάρχουν πολλά NULLs σε γνωρίσµατα. Να ΜΗΝαπαιτούνται πολλές συνενώσεις για να καταλήξουµε σε µια οντότητα. Αυτές οι οδηγίες δεν ήταν τυπικές (δηλ, δεν στηρίζονταν σε 21-3 κάποιο µαθηµατικό EPL342: Databases υπόβαθρο - Demetris Zeinalipour οπόταν (University ήταν of υποκειµενικές)! Cyprus)

4 Εισαγωγή στην Κανονικοποιήση (Normalization) Κανονικοποιήση (Normalization) : Η συστηµατική (τυπική) διαδικασίαδιασφάλισηςότι το σχήµα µιας βάσης δεδοµένων έχει τις πιο κάτω πρόνοιες: Είναι κατάλληλο για εκτέλεση γενικού είδους επερωτήσεων Είναι ελεύθερο από ορισµένα µη-επιθυµητά χαρακτηριστικά (ανωµαλίες) εισαγωγής, ενηµέρωσης, και διαγραφής τα οποία µπορεί να οδηγήσουν σε απώλεια δεδοµένων Η Κανονικοποιήση ορίζεται το 1970 από τον Edgar Frank "Ted" Codd, τον δηµιουργό του Σχεσιακού Μοντέλου. Αυτό για να επιτευχθεί ευκολότερα η µετάβασητων τότεβάσεων δεδοµένων (ιεραρχικό και δικτυακό µοντέλο) στο σχεσιακό µοντέλο. Ο Coddορίζει µέχρι το 1974 διάφορα επίπεδα Κανονικοποιήσης (1NF, 2NF,3NF και BCNF) τα οποία µπορούν να ακολουθηθούν βήµα-βήµα για προσδιορισµό ενός καλού σχεσιακού σχήµατος. 21-4

5 Εισαγωγή στην Κανονικοποιήση (Normalization) Η Κανονικοποιήσηµιας Βάσης µπορεί να γίνει µε τους ακόλουθους δυο τρόπους: Από Πάνω Προς τα Κάτω (Top-Down Design) Αρχικοποίηση µιας (1) σχέσης που περιλαµβάνει ΌΛΑ τα γνωρίσµατα R(A1, AN) µιας εφαρµογής. Η σχέση διασπάται αναδροµικά από πάνω προς τα κάτω µέχρι να φτάσουµε σε σχέσεις οι οποίες πληρούν κάποιο επιθυµητό επίπεδο «Χρηστότητας». Ονοµάζεται αλλιώς Design by Analysis. Από Κάτω Προς τα Πάνω (Bottom Up Design) Ονοµάζεται αλλιώς Design-by-Synthesis εν θα µελετηθεί στα πλαίσια αυτού του µαθήµατος 21-5

6 Εισαγωγή στην Κανονικοποιήση (Normalization) H Κανονικοποιήση στηρίζεται στην έννοια τον συναρτησιακών εξαρτήσεων (functional dependencies), τα οποία αποτελούν γενίκευση της εννοίας του κλειδιού. Π.χ., SSN {Name, NumberGrade, LetterGrade, Dno} NumberGrade LetterGrade Αυτά θα µελετηθούν εκτενώς στην επόµενη διάλεξη. Προτού δούµε τις πιο πάνω έννοιες θα επιχειρήσουµε να συνοψίσουµεµε άτυπο τρόπο κάποιες γενικές οδηγίες γιατο σχεδιασµόενός καλού σχήµατος µιας σχεσιακής βάσης. 21-6

7 Οδηγία 1: Σηµασιολογία (Semantics) των Γνωρισµάτων Σχέσεων Οδηγία 1: Τα απλά γνωρίσµατα µιας σχέσης πρέπει να έχουν κοινήσηµασιολογία (δηλαδή να αναφέρονται στην ίδια οντότητα) Συγκεκριµένα: Απλά Γνωρίσµατα από διαφορετικές οντότητες (π.χ., EMPLOYEEs, DEPARTMENTs, PROJECTs) ΕΝ πρέπει να πλέκονται στην ίδια σχέση ΜΟΝΟ ξένα κλειδιά πρέπει να χρησιµοποιούνται για την αναφορά µεταξύ οντοτήτων. Γνωρίσµατα Οντοτήτων και Γνωρίσµατα Συσχετίσεων είναι καλό να διατηρούνται µακριά µεταξύ τους (δες επόµενη διαφάνεια) Αυτά συχνά είναι πηγή για NULL τιµές. Σηµείωση: Μετά την εκτενή απασχόληση σας µε το Σχεσιακό (αλλα και το ER) µοντέλο, πολλά από τα πιο πάνω µπορεί να σας ακούγονται φυσιολογικά και να τα εφαρµόζεται ήδη. 21-7

8 Οδηγία 1: Σηµασιολογία (Semantics) των Γνωρισµάτων Σχέσεων Παράδειγµα Ανάµειξης Γνωρισµάτων Πιο κάτω δείχνουµε δυο παραδείγµατα σχέσεων που αναµειγνύουν γνωρίσµατα µεταξύ οντοτήτων οδηγώντας µας σε ένα σχεσιακό σχήµα µε φτωχό design Ανάµειξη Employee Department Ανάµειξη Employee Project Σηµείωση: Τα πιο πάνω έχουν φτωχό design ως φυσικές σχέσεις (base relations)όπως θα δούµε σε λίγο. Από την άλλη δεν έχουν ιδιαίτερο σχεδιαστικό πρόβληµα ως όψεις (νοητές σχέσεις) 21-8

9 Οδηγία 1: Σηµασιολογία (Semantics) των Γνωρισµάτων Σχέσεων Συµπέρασµα: Θα πρέπει κανείς να µπορεί να περιγράφει µια-µια τις σχέσεις του σχήµατος µιας βάσης χωρίς να προκύπτουν σηµασιολογικές αµφιβολίες (semantic ambiguities). Π.χ., Project.Dnum εύκολα µας παραπέµπει στο number του department Ενώ εάν ήταν απλά Project.Num τότε δεν θα ήταν ξεκάθαρη η σηµασιολογία του εν λόγω γνωρίσµατος. Αυτό επιτυγχάνεται µε την χρήση ξεκάθαρων ονοµάτων στις σχέσεις και τα γνωρίσµατα. 21-9

10 Πλεονάζουσα Πληροφορία (Προβλήµατα) Πλεονάζουσα Πληροφορία σε Σχέσεις: εδοµένα τα οποία αποθηκεύονται επαναληπτικά (redundantly)προκαλούν τα ακόλουθα προβλήµατα: Α) Σπαταλούν Χώρο Αποθήκευσης, εάν και αυτό το πρόβληµα είναι µικρό σε σχέση µε το επόµενο Β) Προκαλούν προβλήµατα µε τις ενηµερώσεις (update anomalies) Ανωµαλίες Εισαγωγής (Insertion anomalies) Ανωµαλίες ιαγραφής (Deletion anomalies) Ανωµαλίες Τροποποίησης (Modification anomalies) Ας δούµε κάποια παραδείγµατα 21-10

11 Α) Σπατάλη Χώρου Αποθήκευσης (Redundancy) σε δυο σχέσεις Emp_Deptκαι Εmp_Proj Και οι δυο περιπτώσεις είναι αποτέλεσµα άκοµψου σχεδιασµού του σχήµατος των πινάκων Πλεονάζουσα Πληροφορία (Σπατάλη Χώρου) 21-11

12 Ανωµαλίες Ενηµερώσεων (Insert Anomaly) Ανωµαλία Εισαγωγής (Insert Anomaly) Πρόβληµα 1: Για εισαγωγή νέας πλειάδας πρέπει να βεβαιωθούµε ότι το (Dname, Dmgr_ssn) είναι συνεπές µε τις προηγούµενες εγγραφές. Π.χ., Dname= Research, Dmgr_ssn= λάθος. Γιατί; Πρόβληµα 2: εν µπορούµε να εισάγουµε τα στοιχεία ενός Department το οποίο δεν έχει ακόµη employees! εν γίνεται ούτε εάν βάλουµε NULL στα ανύπαρκτα πεδία. Γιατί; 21-12

13 Ανωµαλίες Ενηµερώσεων (Insert Anomaly) Το πιο κάτω στιγµιότυπο των Employee- Department δεν υποφέρει από τις ανωµαλίες εισαγωγής της προηγούµενης σελίδας Α) εν χρειάζεται έλεγχος συνέπειας για εισαγωγήστο Department ή Employee Β) Μπορούµε να εισάγουµε Departments, Employees ανεξάρτητα το ένα από την ύπαρξη του άλλου

14 Ανωµαλίες Ενηµερώσεων (Delete Anomaly) Ανωµαλία ιαγραφής (Delete Anomaly) Πρόβληµα: Εάν σβήσουµετην τελευταία πλειάδα που περιέχει τα στοιχεία ενός Department, τότε θα χαθούν όλες οι πληροφορίες του εν λόγω Department. Π.χ., DELETE FROM EMP_DEPT WHERE SSN= Το πρόβληµα αυτό ΕΝθα προκύψει στο στιγµιότυπο της προηγούµενης διαφάνειας όπου τα στοιχεία ενός department συνεχίζουν να διατηρούνται στον πίνακα Department 21-14

15 Ανωµαλίες Ενηµερώσεων (Update Anomaly) Ανωµαλία Ενηµέρωσης (Update Anomaly) Πρόβληµα: Εάν ενηµερώσουµε το γνώρισµα ενός στοιχείου το οποιοεπαναλαµβάνεταιτότε πρέπει να ενηµερώσουµε ΟΛΕΣ τις εµφανίσεις του. Αυτό το πρόβληµα είναι το µικρότερο από τα αναφερόµενα διότι λύνεται µε µια έκφραση SQL. Π.χ., UPDATE EMP_DEPT SET Dname= RES WHERE Dname= Research εάν και το query θα απαιτεί περισσότερο χρόνο από ότι πρέπει 21-15

16 Οδηγία 2: Πλεονάζουσα Πληροφορία και Ανωµαλίες Ενηµερώσεων Οδηγία 2: Σχεδίασε ένα σχήµα το οποίο ΕΝθα υποφέρει από ανωµαλίες εισαγωγών, διαγραφώνκαι ενηµερώσεων. Εάν είναι ανάγκηνα υφίστανταικάποιες ανωµαλίες (π.χ., για λόγους επίδοσης*), τότε αυτές πρέπει να αναφερθούνκαι τεκµηριωθούν ρητάγια να λαµβάνονται υπόψη από την εφαρµογή. * π.χ., σε εφαρµογές OLAP: Online Analytical Processing όπου ο φόρτος είναι κυρίως Readonly (χωρίς πολλές ενηµερώσεις) 21-16

17 Οδηγία 2: Πλεονάζουσα Πληροφορία και Ανωµαλίες Ενηµερώσεων Από-κανονικοποιήση (Denormalization) Όπως αναφέραµε πριν, σε κάποιες περιπτώσεις ένας DBA µπορεί να κρατήσει το σχήµα µιας βάσης σε κακή δοµή (µη-κανονικοποιηµένη µορφή). Π.χ., Εάν έχουµε ένα συνεχόµενο φόρτο επερωτήσεωνστον πίνακα EMP_DEPT τότε ο µη-κανονικοποιηµένος πίνακας αποφεύγει τη συνεχή συνένωση EMP µε DEPT. Σηµειώστε ότι οι απλές Όψεις δεν βοηθάνε εφόσον πρόκειται απλά για αποθηκευµένα SELECT ερωτήµατα. Σε αυτές τις περιπτώσεις χρειάζεται η βάση να υλοποιεί, µε χρήση σκανδαλών (triggers), µηχανισµώνγια αποφυγή των διάφορων ανωµαλιών ενηµέρωσης. π.χ., κατά την ενηµέρωση µιας πλειάδας αυτόµατα ενηµερώνονται όλες οι άλλες σχετικές πλειάδες 21-17

18 Οδηγία 3: Τιµες NULL σε Πλειάδες Οδηγία 3: Οι σχέσεις πρέπει να σχεδιάζονται έτσι ώστε να έχουν όσο το δυνατό λιγότερες εµφανίσεις NULL. Π.χ., GOOD: Employee(SSN, Dno) Είναι αναµενόµενο ότι οι περισσότεροι Employees θα ανήκουνσε ένα Department οπόταν δικαιολογείται η συµµετοχή του εν λόγω γνωρίσµατος στην σχέση Employee. Γνωρίσµατα που εµφανίζουν συχνά NULL πρέπει να τοποθετούνται σε ξεχωριστές σχέσεις (µαζί µε το πρωτεύων κλειδί της σχέσης) Π.χ., Μόνο το 10% των Employees έχουν γραφείο. BAD: EMPLOYEE(SSN, Name, Officedetails,...) GOOD: EMPLOYEE(SSN, Name,.) EMP_OFFICE(SSN, Οfficedetails) 21-18

19 Οδηγία 4: Πλασµατικές Πλειάδες (Spurious Tuples) Κατά την φάση της top-down κανονικοποιήσης, πολλές σχέσεις καλούνται αναδροµικά να διασπαστούν σε µικρότερες σχέσεις. ιασπώντας (Decomposing) λανθασµένα µια σχέση R κρύβει τους ακόλουθους δυο κινδύνους: A) Επανασύνθεση: Είναι δυνατό να ΜΗΝµπορούµε να επανασυνθέσουµετην Rχάνοντας πολύτιµη σηµασιολογία της εφαρµογής Π.χ., εάν το κλειδί της R δεν περιέχεται τόσο στην Α όσο και στην Β. Β) Πλασµατικές Πλειάδες:Είναι δυνατό να δηµιουργούνται Πλασµατικές Πλειάδες (Spurious Tuples), δηλαδή πλειάδες που δεν άνηκαν στην R. Ακολουθούν παραδείγµατα για το Β

20 Οδηγία 4: Πλασµατικές Πλειάδες (Spurious Tuples) Κανονικό Αποτέλεσµα (Χωρίς Πλασµατικές Πλειάδες) * Λάθος Αποτέλεσµα Με Πλασµατικές Πλειάδες Το λάθος αποτέλεσµα είναι λόγω της κακής δοµής του EMP_LOCS που δεν έχει το SSN 21-20

21 Οδηγία 4 Πλασµατικές Πλειάδες (Spurious Tuples) Οδηγία 4: Οι σχέσεις πρέπει να σχεδιάζονται έτσι ώστε να µπορούν να επανσυνθετούν, τυπικά λέγεται ότι θα πρέπει να ισχύει το lossless join condition, * (π R1 (r),..., π Rm (r)) = r ΕΝπρέπει να παράγονταιπλασµατικές πλειάδες κατά την φυσική συνένωση µεταξύ ΟΠΟΙΩΝ ΗΠΟΤΕ σχέσεων µε κοινά γνωρίσµατα συνένωσης. Υπάρχουν 2 σηµαντικές ιδιότητεςτης διάσπασης (decomposition)µιας σχέσης: a) ιαφύλαξη της Αρχικής Σχέσης: Lossless Join Decomposition εν µπορεί να παραβλεφθεί. b) ιαφύλαξη των Συναρτησιακών Εξαρτήσεων: Functional dependency preservation Μπορεί κάποτε να παραβλεφθεί. Περισσότερα σε ερχόµενες διαλέξεις 21-21