Skip to main content

Κάνοντας μια βάση δεδομένων σε δεύτερη κανονική μορφή (2NF)

Build Tomorrow's Library by Jeffrey Licht (Ενδέχεται 2024)

Build Tomorrow's Library by Jeffrey Licht (Ενδέχεται 2024)

Πίνακας περιεχομένων:

Anonim

Έχουμε εξετάσει διάφορες πτυχές της ομαλοποίησης ενός πίνακα βάσης δεδομένων. Πρώτον, συζητήσαμε τις βασικές αρχές της ομαλοποίησης της βάσης δεδομένων. Τελευταία φορά, διερευνήσαμε τις βασικές απαιτήσεις που καθορίζονται από το πρώτο κανονικό έντυπο (1NF). Τώρα, ας συνεχίσουμε το ταξίδι μας και να καλύψουμε τις αρχές της δεύτερης κανονικής μορφής (2NF).

Οι Γενικές Απαιτήσεις του 2NF

  • Καταργήστε υποσύνολα δεδομένων που ισχύουν για πολλές σειρές πίνακα και τοποθετήστε τα σε ξεχωριστούς πίνακες.
  • Δημιουργήστε σχέσεις μεταξύ αυτών των νέων πινάκων και των προκατόχων τους μέσω της χρήσης ξένων κλειδιών.

Αυτοί οι κανόνες μπορούν να συνοψιστούν σε μια απλή δήλωση: Το 2NF επιχειρεί να μειώσει την ποσότητα των πλεονασμάτων δεδομένων σε έναν πίνακα, εξάγοντάς τον, τοποθετώντας τον σε νέο πίνακα και δημιουργώντας σχέσεις μεταξύ αυτών των πινάκων.

Ας δούμε ένα παράδειγμα. Φανταστείτε ένα ηλεκτρονικό κατάστημα που διατηρεί τις πληροφορίες πελατών σε μια βάση δεδομένων. Μπορεί να έχουν ένα μόνο τραπέζι που ονομάζεται Πελάτες με τα ακόλουθα στοιχεία:

  • CustNum
  • Ονομα
  • Επίθετο
  • Διεύθυνση
  • Πόλη
  • κατάσταση
  • φερμουάρ

Μια σύντομη ματιά σε αυτό το τραπέζι αποκαλύπτει μια μικρή ποσότητα περιττών δεδομένων. Αποθηκεύουμε τις καταχωρήσεις "Sea Cliff, NY 11579" και "Miami, FL 33157" δύο φορές το καθένα. Τώρα, αυτό μπορεί να μην φαίνεται σαν υπερβολική προσθήκη στο απλό μας παράδειγμα, αλλά φανταστείτε το σπαταλημένο χώρο εάν είχαμε χιλιάδες σειρές στο τραπέζι μας. Επιπλέον, εάν επρόκειτο να αλλάξει ο ταχυδρομικός κώδικας για το Sea Cliff, θα έπρεπε να κάνουμε αυτήν την αλλαγή σε πολλά σημεία σε ολόκληρη τη βάση δεδομένων.

Σε μια δομή βάσης δεδομένων συμβατή με 2ΝΡ, αυτές οι περιττές πληροφορίες εξάγονται και αποθηκεύονται σε ξεχωριστό πίνακα. Ο νέος μας πίνακας (ας το ονομάσουμε ZIPs) μπορεί να έχει τα ακόλουθα πεδία:

  • φερμουάρ
  • Πόλη
  • κατάσταση

Εάν θέλουμε να είμαστε υπερ-αποδοτικοί, μπορούμε να γεμίσουμε το τραπέζι εκ των προτέρων - το ταχυδρομείο παρέχει έναν κατάλογο όλων των έγκυρων ταχυδρομικών κωδικών και των σχέσεών τους πόλης / κράτους. Σίγουρα, αντιμετωπίσατε μια κατάσταση όπου χρησιμοποιήθηκε αυτός ο τύπος βάσης δεδομένων. Κάποιος που λαμβάνει μια παραγγελία ίσως σας ζήτησε πρώτα τον ταχυδρομικό σας κωδικό και στη συνέχεια ήξερε την πόλη και το κράτος από το οποίο τηλεφωνούσατε. Αυτός ο τύπος ρύθμισης μειώνει το σφάλμα του χειριστή και αυξάνει την απόδοση.

Τώρα που έχουμε αφαιρέσει τα διπλότυπα δεδομένα από τον πίνακα πελατών, έχουμε ικανοποιήσει τον πρώτο κανόνα της δεύτερης κανονικής φόρμας. Πρέπει να χρησιμοποιήσουμε ένα ξένο κλειδί για να συνδέσουμε μαζί τα δύο τραπέζια. Θα χρησιμοποιήσουμε τον ταχυδρομικό κώδικα (το πρωτεύον κλειδί από τον πίνακα ZIP) για να δημιουργήσουμε αυτή τη σχέση. Εδώ είναι ο νέος πίνακας Πελατών μας:

  • CustNum
  • Ονομα
  • Επίθετο
  • Διεύθυνση
  • φερμουάρ

Τώρα έχουμε ελαχιστοποιήσει την ποσότητα των πλεονάζοντων πληροφοριών που είναι αποθηκευμένες στη βάση δεδομένων και η δομή μας βρίσκεται σε δεύτερη κανονική μορφή.