Πώς να σχεδιάσετε μια βάση δεδομένων που αντέχει στην ανάπτυξη της επιχείρησης

Η βάση δεδομένων ξεκινά από τη λειτουργία της επιχείρησης

Ο σωστός σχεδιασμός βάσης δεδομένων για επιχειρήσεις ξεκινά από τις πραγματικές διαδικασίες, τους ανθρώπους που τις εκτελούν και τα ερωτήματα που πρέπει να απαντά το σύστημα. Δεν ξεκινά από τις οθόνες ή από μια πρόχειρη αντιγραφή των φύλλων Excel. Όταν η δομή σχεδιαστεί βιαστικά, το κόστος φαίνεται αργότερα: λάθος αναφορές, αργές λειτουργίες και δύσκολες αλλαγές.

Ένα Excel μπορεί να εξυπηρετεί μια μικρή ομάδα για αρκετό καιρό. Όταν όμως πολλοί χρήστες ενημερώνουν τα ίδια δεδομένα, χρειάζονται ιστορικό αλλαγών ή συνδέονται παραγγελίες, αποθήκη και τιμολόγηση, οι χειροκίνητες λύσεις αρχίζουν να δημιουργούν ασυνέπειες. Η εφαρμογή χρειάζεται τότε μια σαφή βάση, με κανόνες που δεν εξαρτώνται από το αν κάποιος θυμήθηκε να συμπληρώσει σωστά ένα κελί.

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

Από τις επιχειρησιακές έννοιες στις οντότητες και τις σχέσεις

Μια σχεσιακή βάση δεδομένων αποθηκεύει πληροφορίες σε πίνακες που συνδέονται μεταξύ τους. Κάθε πίνακας περιγράφει μια έννοια της επιχείρησης και κάθε γραμμή περιγράφει μία συγκεκριμένη εγγραφή. Οι στήλες κρατούν τα επιμέρους χαρακτηριστικά της.

Ας πάρουμε ένα απλό παράδειγμα. Σε ένα σύστημα πωλήσεων μπορεί να υπάρχουν οι εξής οντότητες:

• Πελάτης: όνομα, στοιχεία επικοινωνίας και εμπορικά δεδομένα.
• Προϊόν: κωδικός, περιγραφή, τιμή και μονάδα μέτρησης.
• Παραγγελία: ημερομηνία, πελάτης, κατάσταση και συνολικά στοιχεία.
• Γραμμή παραγγελίας: προϊόν, ποσότητα και τιμή κατά τη στιγμή της παραγγελίας.

Η παραγγελία συνδέεται με έναν πελάτη, ενώ ένας πελάτης μπορεί να έχει πολλές παραγγελίες. Αυτή είναι σχέση ένα προς πολλά. Μια παραγγελία μπορεί επίσης να περιέχει πολλά προϊόντα και ένα προϊόν να βρίσκεται σε πολλές παραγγελίες. Εδώ έχουμε σχέση πολλά προς πολλά. Συνήθως υλοποιείται με έναν ενδιάμεσο πίνακα, όπως ο πίνακας «γραμμές παραγγελίας».

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

Αυτή η λογική πρέπει να παραμένει ανεξάρτητη από τις οθόνες. Μια οθόνη μπορεί να αλλάξει, να ενωθεί με άλλη ή να αντικατασταθεί από ένα API, δηλαδή μια προγραμματιστική διεπαφή για ανταλλαγή δεδομένων. Οι επιχειρησιακές έννοιες και οι σχέσεις τους, όμως, πρέπει να παραμένουν κατανοητές.

Πόση κανονικοποίηση χρειάζεται πραγματικά;

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

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

Η κανονικοποίηση προστατεύει κυρίως τρεις λειτουργίες: την εισαγωγή νέων δεδομένων, την ενημέρωση υπαρχόντων και τη διαγραφή. Αποφεύγει, για παράδειγμα, να χαθεί το μοναδικό ιστορικό ενός προϊόντος επειδή διαγράφηκε μια παραγγελία που το περιείχε.

Ωστόσο, περισσότερη διάσπαση δεν σημαίνει πάντα καλύτερο αποτέλεσμα. Ένα υπερβολικά διασπασμένο μοντέλο μπορεί να απαιτεί πολλές συνδέσεις πινάκων για ένα συνηθισμένο ερώτημα. Αυτό δυσκολεύει την ανάπτυξη και τη συντήρηση, ενώ σε ορισμένες περιπτώσεις επηρεάζει και την απόδοση.

Η αποκανονικοποίηση μπορεί να έχει θέση, αλλά μόνο όταν υπάρχει συγκεκριμένο πρόβλημα, πραγματικό ερώτημα και μέτρηση πριν και μετά. Δεν είναι καλή πρακτική να αντιγράφονται δεδομένα «για να είναι πιο γρήγορα» χωρίς να έχει εξεταστεί πρώτα το ερώτημα και το σχέδιο εκτέλεσής του. Η απόφαση πρέπει να καταγράφεται, ώστε ο επόμενος developer να γνωρίζει γιατί υπάρχει η εξαίρεση.

Οι περιορισμοί ακεραιότητας προστατεύουν την αξιοπιστία των δεδομένων

Οι περιορισμοί ακεραιότητας είναι κανόνες που επιβάλλονται στη βάση και όχι μόνο στον κώδικα της εφαρμογής. Αυτό έχει σημασία, επειδή τα δεδομένα μπορεί να εισαχθούν από διαφορετική οθόνη, από import, από άλλο σύστημα ή από μια μελλοντική διασύνδεση.

• PRIMARY KEY: εξασφαλίζει ότι κάθε εγγραφή έχει μοναδική ταυτότητα.
• FOREIGN KEY: εμποδίζει συνδέσεις με εγγραφές που δεν υπάρχουν και περιορίζει τις ορφανές εγγραφές.
• NOT NULL: απαιτεί τιμή σε πεδία που είναι απαραίτητα για τη λειτουργία.
• UNIQUE: αποτρέπει διπλές τιμές όπου πρέπει να υπάρχει μοναδικότητα, όπως ένας κωδικός.
• CHECK: επιβάλλει λογικούς κανόνες, όπως ποσότητα μεγαλύτερη του μηδενός.

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

Χρειάζεται επίσης σαφής ορισμός για τις καταστάσεις. Είναι διαφορετικό το «πρόχειρη», «επιβεβαιωμένη», «απεσταλμένη» και «ακυρωμένη». Αν το σύστημα επιτρέπει οποιοδήποτε κείμενο σε ένα πεδίο status, κάθε χρήστης μπορεί να γράφει κάτι διαφορετικό. Οι αναφορές θα πρέπει μετά να μαντέψουν τι σημαίνει κάθε τιμή.

Ευρετήρια και ερωτήματα: η απόδοση κρίνεται στις λεπτομέρειες

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

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

Η επιλογή πρέπει να βασίζεται σε πραγματικά ερωτήματα. Το EXPLAIN, δηλαδή η ανάλυση του τρόπου με τον οποίο η μηχανή εκτελεί ένα ερώτημα, βοηθά την ομάδα να δει αν χρησιμοποιείται το σωστό ευρετήριο ή αν γίνεται περιττή ανάγνωση δεδομένων. Χρειάζεται να εξεταστεί και η επιλεκτικότητα. Μια στήλη με ελάχιστες διαφορετικές τιμές, όπως ένα πεδίο που έχει μόνο «ναι» και «όχι», δεν θα ωφελεί πάντα από ένα απλό ευρετήριο.

Η απόδοση βάσης δεδομένων δεν κρίνεται από έναν γενικό κανόνα. Κρίνεται από τα ερωτήματα που χρησιμοποιεί πραγματικά η εφαρμογή, τον όγκο των δεδομένων και τον τρόπο με τον οποίο μεγαλώνει η χρήση.

Τι πρέπει να ελέγξετε μαζί με τους developers πριν ξεκινήσει η υλοποίηση

Πριν εγκρίνετε τον σχεδιασμό custom εφαρμογής, ζητήστε απαντήσεις στα παρακάτω. Δεν χρειάζεται να γράψετε κώδικα. Χρειάζεται να γνωρίζετε τι συμφωνήθηκε και γιατί.

• Ροές εργασίας: Έχουν καταγραφεί οι βασικές διαδικασίες από τη δημιουργία έως την ολοκλήρωση μιας συναλλαγής;
• Ιδιοκτησία δεδομένων: Ποιος δημιουργεί, ελέγχει και διορθώνει κάθε βασική πληροφορία;
• Ποιότητα: Πώς αποφεύγονται οι διπλοί πελάτες, οι ελλιπείς τιμές και οι διαφορετικές μορφές στο ίδιο πεδίο;
• Ονομασία: Είναι σαφή και συνεπή τα ονόματα πινάκων και πεδίων; Υπάρχει λεξικό δεδομένων;
• Ιστορικό: Χρειάζεται να γνωρίζετε ποιος άλλαξε μια τιμή και πότε;
• Διαγραφές: Τα δεδομένα διαγράφονται οριστικά ή σημειώνονται ως ανενεργά; Τι γίνεται με τις σχετικές εγγραφές;
• Δικαιώματα: Ποιοι χρήστες μπορούν να βλέπουν, να αλλάζουν ή να εξάγουν ευαίσθητα δεδομένα;
• Αναφορές: Ποιες αναφορές χρειάζονται από την πρώτη ημέρα και ποιες θα προστεθούν αργότερα;
• Μεταφορά: Πώς θα ελεγχθούν και θα καθαριστούν τα δεδομένα από το παλιό σύστημα ή τα αρχεία Excel;
• Ασφάλεια και αντίγραφα: Πόσο συχνά λαμβάνονται αντίγραφα ασφαλείας και έχει δοκιμαστεί η επαναφορά τους;
• Έλεγχος απόδοσης: Θα χρησιμοποιηθούν δοκιμαστικά δεδομένα που μοιάζουν σε μέγεθος με την πραγματική χρήση;
• Μελλοντικές αλλαγές: Πώς θα προστίθενται νέα πεδία, καταστάσεις, ρόλοι ή διασυνδέσεις χωρίς πρόχειρες παρεμβάσεις;

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

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

Ένα μικρότερο αρχικό σχέδιο μπορεί να αντέξει περισσότερο

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

Αν το έργο χρειάζεται σύνθετη επιχειρηματική λογική ή διασύνδεση με άλλα συστήματα, η Saikō μπορεί να βοηθήσει στην ανάλυση και στον σχεδιασμό custom εφαρμογής, ξεκινώντας από τον τρόπο με τον οποίο εργάζεται πραγματικά η επιχείρηση.