Γειά σου! Ονομάζομαι Andrey Semenov, είμαι ανώτερος αναλυτής στο Sportmaster. Σε αυτήν την ανάρτηση θέλω να θίξω το θέμα της αποκανονικοποίησης των βάσεων δεδομένων συστημάτων ERP. Θα δούμε γενικές συνθήκες, καθώς και ένα συγκεκριμένο παράδειγμα - ας πούμε ότι θα ήταν μια υπέροχη μονοπωλιακή ταβέρνα για πειρατές και ναυτικούς. Στο οποίο οι πειρατές και οι ναυτικοί πρέπει να εξυπηρετούνται διαφορετικά, γιατί οι ιδέες ομορφιάς και τα καταναλωτικά πρότυπα αυτών των καλών κυρίων διαφέρουν σημαντικά.
Πώς να κάνετε όλους χαρούμενους; Πώς μπορείτε να αποφύγετε να τρελαθείτε σχεδιάζοντας και συντηρώντας ένα τέτοιο σύστημα; Τι να κάνετε αν όχι μόνο οι συνηθισμένοι πειρατές και ναυτικοί αρχίσουν να έρχονται στην ταβέρνα;
Όλα είναι κάτω από το κόψιμο. Πάμε όμως με τη σειρά.
1. Περιορισμοί και υποθέσεις
Όλα τα παραπάνω ισχύουν μόνο για σχεσιακές βάσεις δεδομένων. Οι συνέπειες της αποκανονικοποίησης με τη μορφή ανωμαλιών τροποποίησης, διαγραφής και εισαγωγής, οι οποίες καλύπτονται καλά, συμπεριλαμβανομένου του Διαδικτύου, δεν λαμβάνονται υπόψη. Εκτός του πεδίου αυτής της δημοσίευσης υπάρχουν περιπτώσεις όπου η αποσυναρμολόγηση είναι συνηθισμένη, με κλασικά παραδείγματα: σειρά και αριθμός διαβατηρίου, ημερομηνία και ώρα κ.λπ.
Η ανάρτηση χρησιμοποιεί διαισθητικούς και πρακτικά εφαρμόσιμους ορισμούς κανονικών μορφών, χωρίς αναφορά σε μαθηματικούς όρους. Με τη μορφή που μπορούν να εφαρμοστούν στην εξέταση πραγματικών επιχειρηματικών διαδικασιών (BP) και στο σχεδιασμό βιομηχανικού λογισμικού.
Υποστηρίζεται ότι ο σχεδιασμός των αποθηκών δεδομένων, των εργαλείων αναφοράς και των συμφωνιών ολοκλήρωσης (που χρησιμοποιούν αναπαραστάσεις σε πίνακα πληροφοριών) διαφέρει από τον σχεδιασμό βάσεων δεδομένων συστημάτων ERP στο ότι η ευκολία κατανάλωσης και η χρήση συνειδητής αποκανονικοποίησης για την επίτευξή της μπορεί να υπερισχύει της ακεραιότητας. δεδομένα προστασίας. Συμμερίζομαι αυτήν την άποψη και αυτό που περιγράφεται παρακάτω ισχύει αποκλειστικά για τα κύρια δεδομένα και τα μοντέλα δεδομένων συναλλαγών των συστημάτων ERP.
Μια εξήγηση των κανονικών μορφών δίνεται χρησιμοποιώντας ένα παράδειγμα που είναι κατανοητό σε καθημερινό επίπεδο για τους περισσότερους αναγνώστες. Ωστόσο, ως οπτική απεικόνιση, στις παραγράφους 4-5, χρησιμοποιήθηκε σκόπιμα μια σκόπιμα «φανταστική» εργασία. Εάν δεν το κάνετε αυτό και πάρετε ένα παράδειγμα σχολικού βιβλίου, για παράδειγμα, το ίδιο μοντέλο αποθήκευσης παραγγελίας από το σημείο 2, μπορεί να βρεθείτε σε μια κατάσταση όπου η εστίαση του αναγνώστη θα μετατοπιστεί από την προτεινόμενη αποσύνθεση της διαδικασίας σε μοντέλο. στην προσωπική εμπειρία και αντίληψη του τρόπου με τον οποίο πρέπει να δημιουργηθούν οι διαδικασίες και τα μοντέλα για την αποθήκευση δεδομένων στο IS. Με άλλα λόγια, πάρτε δύο ειδικευμένους αναλυτές πληροφορικής, αφήστε τον έναν να παρέχει υπηρεσίες σε επιμελητές που μεταφέρουν επιβάτες, ο άλλος σε επιμελητές που μεταφέρουν μηχανήματα για την παραγωγή μικροτσίπ. Ζητήστε τους, χωρίς να συζητήσετε εκ των προτέρων τα αυτοματοποιημένα BP, να δημιουργήσουν ένα μοντέλο δεδομένων για την αποθήκευση πληροφοριών σχετικά με ένα σιδηροδρομικό ταξίδι.
Υπάρχει μια μη μηδενική πιθανότητα ότι στα προτεινόμενα μοντέλα θα βρείτε όχι μόνο ένα αισθητά διαφορετικό σύνολο χαρακτηριστικών, αλλά και διαφορετικά σύνολα οντοτήτων, επειδή κάθε αναλυτής θα βασιστεί στις διαδικασίες και τις εργασίες που είναι γνωστές σε αυτόν. Και σε μια τέτοια κατάσταση είναι αδύνατο να πούμε ποιο μοντέλο είναι «σωστό», γιατί δεν υπάρχει κριτήριο αξιολόγησης.
2. Κανονικές μορφές
Πρώτη κανονική μορφή της βάσης δεδομένων απαιτεί ατομικότητα όλων των ιδιοτήτων.
Ειδικότερα, εάν το αντικείμενο Α έχει χαρακτηριστικά μη κλειδιού a και b, έτσι ώστε c=f(a,b) και στον πίνακα που περιγράφει το αντικείμενο A αποθηκεύετε την τιμή του χαρακτηριστικού c, τότε η πρώτη κανονική μορφή παραβιάζεται στη βάση δεδομένων . Για παράδειγμα, εάν η προδιαγραφή παραγγελίας υποδεικνύει μια ποσότητα, οι μονάδες μέτρησης της οποίας εξαρτώνται από τον τύπο του προϊόντος: σε μια περίπτωση μπορεί να είναι κομμάτια, σε άλλη λίτρα, σε μια τρίτη συσκευασία που αποτελείται από τεμάχια (στο μοντέλο παραπάνω Good_count_WR) , τότε η ατομικότητα των χαρακτηριστικών παραβιάζεται στη βάση δεδομένων. Σε αυτήν την περίπτωση, για να πείτε ποιο θα πρέπει να είναι το σύμπλεγμα πινάκων της προδιαγραφής παραγγελίας, χρειάζεστε μια στοχευμένη περιγραφή της διαδικασίας εργασίας στο IS και επειδή οι διαδικασίες μπορεί να είναι διαφορετικές, μπορεί να υπάρχουν πολλές "σωστές" εκδόσεις.
Δεύτερη κανονική μορφή της βάσης δεδομένων απαιτεί συμμόρφωση με την πρώτη φόρμα και τον δικό της πίνακα για κάθε οντότητα που σχετίζεται με τη διαδικασία εργασίας στο IS. Αν σε έναν πίνακα υπάρχουν εξαρτήσεις c=f1(a) και d=f2(b) και δεν υπάρχει εξάρτηση c=f3(b), τότε η δεύτερη κανονική μορφή παραβιάζεται στον πίνακα. Στο παραπάνω παράδειγμα, δεν υπάρχει εξάρτηση μεταξύ παραγγελίας και διεύθυνσης στον πίνακα Παραγγελίας. Αλλάξτε το όνομα της οδού ή της πόλης και δεν θα έχετε καμία επίδραση στα βασικά χαρακτηριστικά της παραγγελίας.
Τρίτη βάση δεδομένων κανονικής μορφής απαιτεί συμμόρφωση με τη δεύτερη κανονική μορφή και την απουσία λειτουργικών εξαρτήσεων μεταξύ των χαρακτηριστικών διαφορετικών οντοτήτων. Αυτός ο κανόνας μπορεί να διατυπωθεί ως εξής: «ό,τι μπορεί να υπολογιστεί πρέπει να υπολογίζεται». Με άλλα λόγια, εάν υπάρχουν δύο αντικείμενα Α και Β. Στον πίνακα που αποθηκεύει τις ιδιότητες του αντικειμένου Α, εμφανίζεται το χαρακτηριστικό C και το αντικείμενο Β έχει χαρακτηριστικό b, έτσι ώστε να υπάρχει c=f4(b), τότε η τρίτη κανονική μορφή παραβιάζεται. Στο παρακάτω παράδειγμα, το χαρακτηριστικό Quantity of Pieces (Total_count_WR) στην εγγραφή παραγγελίας ισχυρίζεται σαφώς ότι παραβαίνει την τρίτη κανονική φόρμα
3. Η προσέγγισή μου στην εφαρμογή της κανονικοποίησης
1. Μόνο μια στοχευόμενη αυτοματοποιημένη επιχειρηματική διαδικασία μπορεί να παρέχει στον αναλυτή κριτήρια για τον εντοπισμό οντοτήτων και χαρακτηριστικών κατά τη δημιουργία ενός μοντέλου αποθήκευσης δεδομένων. Η δημιουργία ενός μοντέλου διαδικασίας αποτελεί προϋπόθεση για τη δημιουργία ενός κανονικού μοντέλου δεδομένων.
2. Η επίτευξη τρίτης κανονικής μορφής με τη στενή έννοια μπορεί να μην είναι πρακτική στην πραγματική πρακτική της δημιουργίας συστημάτων ERP εάν πληρούνται ορισμένες ή όλες οι ακόλουθες προϋποθέσεις:
- οι αυτοματοποιημένες διαδικασίες σπάνια υπόκεινται σε αλλαγές,
- οι προθεσμίες για έρευνα και ανάπτυξη είναι περιορισμένες,
- οι απαιτήσεις για ακεραιότητα δεδομένων είναι σχετικά χαμηλές (τα πιθανά σφάλματα στο βιομηχανικό λογισμικό δεν οδηγούν σε απώλεια χρημάτων ή πελατών από τον πελάτη λογισμικού)
- κλπ.
Υπό τις περιγραφόμενες συνθήκες, το κόστος αναγνώρισης και περιγραφής του κύκλου ζωής ορισμένων αντικειμένων και των ιδιοτήτων τους μπορεί να μην δικαιολογείται από την άποψη της οικονομικής απόδοσης.
3. Οποιεσδήποτε συνέπειες αποσυναρμολόγησης του μοντέλου δεδομένων σε ένα ήδη δημιουργημένο IS μπορούν να μετριαστούν με ενδελεχή προκαταρκτική μελέτη του κώδικα και δοκιμή.
4. Η αποκανονικοποίηση είναι ένας τρόπος μεταφοράς του κόστους εργασίας από το στάδιο της έρευνας πηγών δεδομένων και του σχεδιασμού μιας επιχειρηματικής διαδικασίας στο στάδιο ανάπτυξης, από την περίοδο υλοποίησης στην περίοδο ανάπτυξης του συστήματος.
5. Συνιστάται να προσπαθήσετε για την τρίτη κανονική μορφή μιας βάσης δεδομένων εάν:
- Η κατεύθυνση της αλλαγής στις αυτοματοποιημένες επιχειρηματικές διαδικασίες είναι δύσκολο να προβλεφθεί
- Υπάρχει αδύναμος καταμερισμός εργασίας εντός της ομάδας υλοποίησης ή/και ανάπτυξης
- Τα συστήματα που περιλαμβάνονται στο κύκλωμα ολοκλήρωσης αναπτύσσονται σύμφωνα με τα δικά τους σχέδια
- Η ασυνέπεια των δεδομένων μπορεί να έχει ως αποτέλεσμα μια εταιρεία να χάσει πελάτες ή χρήματα
6. Ο σχεδιασμός ενός μοντέλου δεδομένων θα πρέπει να πραγματοποιείται από έναν αναλυτή μόνο σε σχέση με τα μοντέλα της επιχειρηματικής διαδικασίας στόχου και της διαδικασίας στο IS. Εάν ένας προγραμματιστής σχεδιάζει ένα μοντέλο δεδομένων, θα πρέπει να βυθιστεί στη θεματική περιοχή σε τέτοιο βαθμό ώστε, ειδικότερα, να κατανοήσει τη διαφορά μεταξύ των τιμών των χαρακτηριστικών - απαραίτητη προϋπόθεση για την απομόνωση ατομικών χαρακτηριστικών. Έτσι, αναλαμβάνοντας ασυνήθιστες λειτουργίες.
4 Πρόβλημα για απεικόνιση
Ας πούμε ότι έχετε μια μικρή ρομποτική ταβέρνα στο λιμάνι. Το τμήμα της αγοράς σας: ναυτικοί και πειρατές που έρχονται στο λιμάνι και χρειάζονται ένα διάλειμμα. Πουλάς τσάι με θυμάρι στους ναυτικούς, και ρούμι και χτένες με κόκαλα για το χτένισμα των γενειάδων στους πειρατές. Η εξυπηρέτηση στην ίδια την ταβέρνα παρέχεται από ρομπότ οικοδέσποινα και ρομπότ μπάρμαν. Χάρη στην υψηλή ποιότητα και τις χαμηλές τιμές σας, έχετε διώξει τους ανταγωνιστές σας, ώστε όλοι όσοι κατεβαίνουν από το πλοίο να έρχονται στην ταβέρνα σας που είναι η μοναδική στο λιμάνι.
Το συγκρότημα πληροφοριακών συστημάτων της ταβέρνας αποτελείται από το ακόλουθο λογισμικό:
- Ένα σύστημα έγκαιρης προειδοποίησης για έναν πελάτη που αναγνωρίζει την κατηγορία του βάσει χαρακτηριστικών χαρακτηριστικών
- Σύστημα ελέγχου για ρομπότ οικοδέσποινες και ρομπότ μπάρμαν
- Σύστημα διαχείρισης αποθήκης και παράδοσης στο σημείο πώλησης
- Σύστημα Διαχείρισης Σχέσεων Προμηθευτών (SURP)
Διαδικασία:
Το σύστημα έγκαιρης προειδοποίησης αναγνωρίζει άτομα που εγκαταλείπουν το πλοίο. Εάν κάποιος είναι ξυρισμένος, τον προσδιορίζει ως ναύτη· εάν κάποιος έχει γένια, τότε αναγνωρίζεται ως πειρατής.
Μπαίνοντας στην ταβέρνα, ο επισκέπτης ακούει έναν χαιρετισμό από την οικοδέσποινα ρομπότ σύμφωνα με την κατηγορία του, για παράδειγμα: "Χο-χο-χο, αγαπητέ πειρατή, πήγαινε στο τραπέζι Νο..."
Ο επισκέπτης πηγαίνει στο καθορισμένο τραπέζι, όπου ο μπάρμαν ρομπότ έχει ήδη ετοιμάσει προϊόντα για αυτόν σύμφωνα με την κατηγορία. Ο μπάρμαν ρομπότ μεταδίδει πληροφορίες στο σύστημα αποθήκης ότι το επόμενο τμήμα της παράδοσης θα πρέπει να αυξηθεί· το IS της αποθήκης, με βάση τα υπόλοιπα στην αποθήκευση, δημιουργεί ένα αίτημα αγοράς στο σύστημα διαχείρισης.
Ενώ το σύστημα έγκαιρης προειδοποίησης μπορεί να έχει αναπτυχθεί από το εσωτερικό σας IT, το πρόγραμμα διαχείρισης ρομπότ μπαρ μπορεί να έχει δημιουργηθεί από εξωτερικό ανάδοχο ειδικά για την επιχείρησή σας. Και τα συστήματα διαχείρισης αποθηκών και σχέσεων με προμηθευτές είναι προσαρμοσμένες συσκευασμένες λύσεις από την αγορά.
5. Παραδείγματα αποκανονικοποίησης και ο αντίκτυπός της στην ανάπτυξη λογισμικού
Κατά το σχεδιασμό μιας επιχειρηματικής διαδικασίας, οι εμπειρογνώμονες του θέματος που συμμετείχαν στη συνέντευξη δήλωσαν ομόφωνα ότι σε όλο τον κόσμο οι πειρατές πίνουν ρούμι και χτενίζουν τα γένια τους με κοκάλινες χτένες και οι ναυτικοί πίνουν τσάι με θυμάρι και είναι πάντα ξυρισμένοι.
Εμφανίζεται ένας κατάλογος τύπων πελατών με δύο τιμές: 1 - πειρατές, 2 - ναυτικοί, κοινές για ολόκληρο το κύκλωμα πληροφοριών της εταιρείας.
Το σύστημα ειδοποίησης πελάτη αποθηκεύει αμέσως το αποτέλεσμα της επεξεργασίας εικόνας ως αναγνωριστικό (ID) του αναγνωρισμένου πελάτη και τον τύπο του: ναύτης ή πειρατής.
Αναγνωρισμένο αναγνωριστικό αντικειμένου
Κατηγορία πελάτη
100500
Πειρατής
100501
Πειρατής
100502
Ναυτικός
Ας το σημειώσουμε για άλλη μια φορά
1. Οι ναυτικοί μας είναι στην πραγματικότητα ξυρισμένοι άνθρωποι
2. Οι πειρατές μας είναι στην πραγματικότητα γενειοφόροι άνθρωποι
Ποια προβλήματα σε αυτή την περίπτωση πρέπει να εξαλειφθούν ώστε η δομή μας να προσπαθεί για την τρίτη κανονική μορφή:
- Παραβίαση της ατομικότητας χαρακτηριστικών - Κατηγορία πελάτη
- αναμειγνύοντας το αναλυόμενο γεγονός και το συμπέρασμα σε έναν πίνακα
- σταθερή λειτουργική σχέση μεταξύ ιδιοτήτων διαφορετικών οντοτήτων.
Σε κανονικοποιημένη μορφή, θα λάβουμε δύο πίνακες:
- αποτέλεσμα αναγνώρισης με τη μορφή ενός συνόλου καθιερωμένων χαρακτηριστικών,
Αναγνωρισμένο αναγνωριστικό αντικειμένου
Τρίχες προσώπου
100500
Ναί
100501
Ναί
100502
Όχι
- το αποτέλεσμα του προσδιορισμού του τύπου πελάτη ως εφαρμογή της λογικής που είναι ενσωματωμένη στο IS για την ερμηνεία των καθιερωμένων χαρακτηριστικών
Αναγνωρισμένο αναγνωριστικό αντικειμένου
Ταυτότητα ταυτότητας
Κατηγορία πελάτη
100500
100001
Πειρατής
100501
100002
Πειρατής
100502
100003
Ναυτικός
Πώς μπορεί ένας κανονικοποιημένος οργανισμός αποθήκευσης δεδομένων να διευκολύνει την ανάπτυξη ενός συμπλέγματος IP; Ας υποθέσουμε ότι αποκτάτε ξαφνικά νέους πελάτες. Ας είναι Ιάπωνες πειρατές που μπορεί να μην έχουν μούσι, αλλά περπατούν με έναν παπαγάλο στον ώμο τους και οικολόγοι πειρατές, τους αναγνωρίζεις εύκολα από το μπλε προφίλ της Γκρέτα στο αριστερό στήθος.
Οι περιβαλλοντικοί πειρατές, φυσικά, δεν μπορούν να χρησιμοποιήσουν κοκάλινα χτένες και απαιτούν ένα ανάλογο κατασκευασμένο από ανακυκλωμένο θαλάσσιο πλαστικό.
Πρέπει να επεξεργαστείτε ξανά τους αλγόριθμους του προγράμματος σύμφωνα με τις νέες εισόδους. Εάν ακολουθούνταν οι κανόνες κανονικοποίησης, τότε θα έπρεπε μόνο να συμπληρώσετε τις εισόδους για ορισμένους κλάδους διεργασιών σε ορισμένα συστήματα και να δημιουργήσετε νέους κλάδους μόνο για εκείνες τις περιπτώσεις και σε εκείνες τις περιοχές όπου οι τρίχες του προσώπου έχουν σημασία. Αλλά, επειδή δεν τηρήθηκαν οι κανόνες, θα πρέπει να αναλύσετε ολόκληρο τον κώδικα, σε ολόκληρο το κύκλωμα, όπου χρησιμοποιούνται οι τιμές του καταλόγου τύπων πελάτη και να καθορίσετε σαφώς ότι σε μια περίπτωση ο αλγόριθμος πρέπει να λαμβάνει υπόψη τον επαγγελματία δραστηριότητα του πελάτη και στα άλλα φυσικά χαρακτηριστικά.
Σε μια μορφή που αναζητά για κανονικοποίηση, θα λάβαμε δύο πίνακες με λειτουργικά δεδομένα και δύο καταλόγους:
- αποτέλεσμα αναγνώρισης με τη μορφή ενός συνόλου καθιερωμένων χαρακτηριστικών,
Αναγνωρισμένο αναγνωριστικό αντικειμένου
Η Γκρέτα στο αριστερό στήθος
Πουλί στον ώμο
Τρίχες προσώπου
100510
1
1
1
100511
0
0
1
100512
1
0
- το αποτέλεσμα του προσδιορισμού του τύπου πελάτη (ας είναι μια προσαρμοσμένη προβολή στην οποία εμφανίζονται περιγραφές από καταλόγους)
Η ανιχνευθείσα αποκανονικοποίηση σημαίνει ότι τα συστήματα δεν μπορούν να τροποποιηθούν ώστε να πληρούν τις νέες συνθήκες; Φυσικά και όχι. Αν φανταστούμε ότι όλα τα πληροφοριακά συστήματα δημιουργήθηκαν από μια ομάδα με μηδενική εναλλαγή προσωπικού, οι εξελίξεις είναι καλά τεκμηριωμένες και οι πληροφορίες μεταφέρονται εντός της ομάδας χωρίς απώλειες, τότε οι απαιτούμενες αλλαγές μπορούν να γίνουν με αμελητέα λίγη προσπάθεια. Αν όμως επιστρέψουμε στις αρχικές συνθήκες του προβλήματος, 1,5 πληκτρολόγια θα διαγραφούν μόνο για την εκτύπωση πρωτοκόλλων κοινών συζητήσεων και άλλο 0,5 για την επεξεργασία των διαδικασιών προμήθειας.
Στο παραπάνω παράδειγμα, παραβιάζονται και οι τρεις κανονικές μορφές, ας προσπαθήσουμε να τις παραβιάσουμε ξεχωριστά.
Παραβίαση της πρώτης κανονικής μορφής:
Ας υποθέσουμε ότι τα εμπορεύματα παραδίδονται στην αποθήκη σας από τις αποθήκες των προμηθευτών με παραλαβή χρησιμοποιώντας μια γαζέλα 1.5 τόνου που ανήκει στην ταβέρνα σας. Το μέγεθος των παραγγελιών σας είναι τόσο μικρό σε σχέση με τον κύκλο εργασιών των προμηθευτών που ολοκληρώνονται πάντα μία προς μία χωρίς να περιμένουν την παραγωγή. Χρειάζεστε ξεχωριστούς πίνακες με μια τέτοια επιχειρηματική διαδικασία: οχήματα, τύποι οχημάτων, είναι απαραίτητο να διαχωρίσετε το σχέδιο και το γεγονός στις παραγγελίες σας σε προμηθευτές που αναχώρησαν;
Απλώς φανταστείτε πόσες «επιπλέον» συνδέσεις θα πρέπει να γράψουν οι προγραμματιστές σας εάν χρησιμοποιήσετε το παρακάτω μοντέλο για να αναπτύξετε ένα πρόγραμμα.
Ας υποθέσουμε ότι αποφασίσαμε ότι η προτεινόμενη δομή είναι αδικαιολόγητα περίπλοκη· στην περίπτωσή μας, ο διαχωρισμός του σχεδίου και του γεγονότος στο αρχείο παραγγελίας είναι περιττές πληροφορίες και η προδιαγραφή παραγγελίας που δημιουργείται ξαναγράφεται με βάση τα αποτελέσματα της αποδοχής των προϊόντων που έφτασε, σπάνια λάθος -η ταξινόμηση και η άφιξη εμπορευμάτων ανεπαρκούς ποιότητας διευθετούνται εκτός του ΚΠ.
Και τότε μια μέρα βλέπεις πώς όλη η αίθουσα της ταβέρνας γεμίζει με αγανακτισμένους και ατημέλητους πειρατές. Τι συνέβη?
Αποδεικνύεται ότι καθώς η επιχείρησή σας μεγάλωνε, το ίδιο αυξανόταν και η κατανάλωσή σας. Μια φορά κι έναν καιρό, πάρθηκε μια απόφαση διαχείρισης ότι εάν μια γαζέλα υπερφορτωθεί σε όγκο ή/και βάρος, κάτι που ήταν εξαιρετικά σπάνιο, ο προμηθευτής θα έδινε προτεραιότητα στο φορτίο υπέρ των ποτών.
Τα μη παραδοθέντα εμπορεύματα κατέληγαν στην επόμενη παραγγελία και έφυγαν με νέα πτήση· η παρουσία ενός ελάχιστου υπολοίπου στην αποθήκη στην ταβέρνα επέτρεψε να μην παρατηρηθούν περιπτώσεις που λείπουν.
Ο τελευταίος ανταγωνιστής έκλεισε στο λιμάνι και η τρυπημένη περίπτωση υπερφόρτωσης γαζέλας, που παρακάμπτεται από την ιεράρχηση προτεραιοτήτων με βάση την υπόθεση της επάρκειας της ελάχιστης ισορροπίας και την περιοδική υποφόρτωση του οχήματος, έγινε κοινή πρακτική. Το δημιουργημένο σύστημα θα λειτουργεί ιδανικά σύμφωνα με τους αλγόριθμους που είναι ενσωματωμένοι σε αυτό και θα στερείται κάθε ευκαιρίας παρακολούθησης της συστηματικής αποτυχίας εκπλήρωσης των προγραμματισμένων παραγγελιών. Μόνο μια κατεστραμμένη φήμη και οι δυσαρεστημένοι πελάτες θα μπορούν να εντοπίσουν το πρόβλημα.
Ένας προσεκτικός αναγνώστης μπορεί να έχει παρατηρήσει ότι η παραγγελθείσα ποσότητα στην προδιαγραφή παραγγελίας (T_ORDER_SPEC) στην ενότητα 2 και στην ενότητα 5 μπορεί να πληροί ή να μην πληροί την απαίτηση της πρώτης κανονικής μορφής. Όλα εξαρτώνται από το εάν, δεδομένης της επιλεγμένης ποικιλίας αγαθών, ουσιαστικά διαφορετικές μονάδες μέτρησης μπορούν να εμπίπτουν στο ίδιο πεδίο.
Παραβίαση δεύτερης κανονικής μορφής:
Καθώς οι ανάγκες σας αυξάνονται, αγοράζετε μερικά ακόμη οχήματα διαφορετικών μεγεθών. Στο παραπάνω πλαίσιο, η δημιουργία καταλόγου οχημάτων θεωρήθηκε περιττή, με αποτέλεσμα όλοι οι αλγόριθμοι επεξεργασίας δεδομένων που εξυπηρετούν τις ανάγκες παράδοσης και αποθήκης να αντιλαμβάνονται τη μετακίνηση του φορτίου από τον προμηθευτή στην αποθήκη ως πτήση ενός αποκλειστικά 1,5 τόνου. γκαζέλλα. Έτσι, μαζί με την αγορά νέων οχημάτων, εξακολουθείτε να δημιουργείτε έναν κατάλογο οχημάτων, αλλά κατά την οριστικοποίησή του, θα πρέπει να αναλύσετε όλο τον κώδικα που αναφέρεται στην κίνηση του φορτίου για να μάθετε εάν σε κάθε συγκεκριμένο μέρος υπονοούνται αναφορές στα χαρακτηριστικά του ίδιου του οχήματος από το οποίο ξεκίνησε η επιχείρηση.
Παραβίαση της τρίτης κανονικής μορφής:
Κάποια στιγμή ξεκινάτε να δημιουργείτε ένα πρόγραμμα αφοσίωσης, εμφανίζεται μια εγγραφή ενός τακτικού πελάτη. Γιατί, για παράδειγμα, να ξοδεύετε χρόνο δημιουργώντας προβολές υλικού που αποθηκεύουν συγκεντρωτικά δεδομένα σχετικά με τις πωλήσεις σε έναν μεμονωμένο πελάτη για χρήση στην αναφορά και μεταφορά σε αναλυτικά συστήματα, εάν στην αρχή ενός προγράμματος επιβράβευσης ό,τι ενδιαφέρει τον πελάτη μπορεί να τοποθετηθεί στο αρχείο του πελάτη ? Και, πράγματι, με την πρώτη ματιά, δεν υπάρχει νόημα. Αλλά κάθε φορά που η επιχείρησή σας συνδέει, για παράδειγμα, νέα κανάλια πωλήσεων, θα πρέπει να υπάρχει κάποιος μεταξύ των αναλυτών σας που θα θυμάται ότι υπάρχει ένα τέτοιο χαρακτηριστικό συνάθροισης.
Κατά το σχεδιασμό κάθε νέας διαδικασίας, για παράδειγμα, πωλήσεις στο Διαδίκτυο, πωλήσεις μέσω διανομέων συνδεδεμένων σε ένα κοινό σύστημα πιστότητας, κάποιος πρέπει να έχει κατά νου ότι όλες οι νέες διαδικασίες πρέπει να διασφαλίζουν την ακεραιότητα των δεδομένων σε επίπεδο κώδικα. Για μια βιομηχανική βάση δεδομένων με χίλιους πίνακες, αυτό φαίνεται σαν αδύνατο έργο.
Ένας έμπειρος προγραμματιστής, φυσικά, ξέρει πώς να σταματήσει όλα τα προβλήματα που αναφέρθηκαν παραπάνω, αλλά, κατά τη γνώμη μου, το καθήκον ενός έμπειρου αναλυτή δεν είναι να τα φέρει στο φως.
Θα ήθελα να εκφράσω την ευγνωμοσύνη μου στον κορυφαίο προγραμματιστή Evgeniy Yarukhin για τα πολύτιμα σχόλιά του κατά την προετοιμασία της δημοσίευσης.
Λογοτεχνία
Connolly Thomas, Begg Caroline. Βάση δεδομένων. Σχεδιασμός, υλοποίηση και υποστήριξη. Θεωρία και πράξη
Πηγή: www.habr.com