Πρώτα Βήματα - Βάσεις δεδομένων

Απ: Σχεσιακές βάσεις χωρίς... σχέσεις;

Panagiotis Kefalidis — Fri, 12 Feb 2010 22:13:42 GMT

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

Απ: Σχεσιακές βάσεις χωρίς... σχέσεις;

Παναγιώτης Καναβός — Fri, 12 Feb 2010 21:33:32 GMT

Βασικά, στον Κεφαλλίδη απευθυνόμουν, που χθες ήταν εδώ και μας άκουγε αλλά φαινεται δεν εννοούσε Όσο για την κανονικοποίηση, στις reporting βάσεις και κυρίως στο data warehouse πάει περίπατο, απλά γιατί οι απαιτήσεις και οι κανόνες είναι άλλοι. Η κανονικοποίηση απαιτείται σε εφαρμογές OLTP, όπου θέλεις να γράφεις/αλλάζεις εύκολα δεδομένα με περίπλοκες σχέσεις μεταξύ τους και η πρόσβαση σε αυτά μπορεί να γίνει με οποιοδήποτε τρόπο.

Στο reporting αντίθετα τα δεδομένα αλλάζουν σπάνια, αλλά διαβάζονται συχνά, οι σχέσεις μεταξύ τους είναι δεδομένες και ο τρόπος πρόσβασης προκαθορισμένος.

Απ: Σχεσιακές βάσεις χωρίς... σχέσεις;

Dimitris Papadimitriou — Fri, 12 Feb 2010 21:01:47 GMT

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

Απ: Σχεσιακές βάσεις χωρίς... σχέσεις;

Παναγιώτης Καναβός — Fri, 12 Feb 2010 20:26:41 GMT

Θα διαφωνίσω όσον αφορά τα MIS και το reporting, και εγώ που φτιάχνω τώρα ένα data warehouse και ο συνάδελφος στο διπλανό γραφείο που φτιάχνει τα reports στο Cognos. Τα Foreign Key constraints τα θες και στις reporting databases ως reference για όποιον άλλο δουλέψει με τη βάση, αλλά και επειδή τα εργαλεία reporting τα χρησιμοποιούν στο σχεδιασμό των μοντέλων τους.
Τέλος, τα θες και για τον πρωταρχικό τους στόχο: τον έλεγχο των δεδομένων. Μία reporting database ή ένα data warehouse πρέπει να περιέχει καθαρή πληροφορία, χωρίς τα λάθη και τις παραλείψεις του OLTP. Ένας τρόπος να το ελέγξεις αυτό είναι με τα Foreign key constraints.

Ο μόνος λόγος να τα αποφύγεις είναι επειδή καθυστερούν πολύ το φόρτωμα των δεδομένων. Γι αυτό και όταν φορτώνεις τα data είτε τα ρίχνεις είτε τα απενεργοποιείς (ανάλογα με τις δυνατότητες της βάσης) και τα επανενεργοποιείς όταν τελειώσει το φόρτωμα. Ο ευκολότερος τρόπος να το κάνεις αυτό είναι με ένα stored procedure.

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

Απ: Σχεσιακές βάσεις χωρίς... σχέσεις;

Johnnyxp64 — Fri, 12 Feb 2010 20:15:28 GMT

Dimitris Papadimitriou:

................. Ναι, υπάρχουν βάσεις δεδομένων χωρίς relationships. Ίσως πολλές φορές τμήματα αυτών. Όπως υπάρχουν και βάσεις (ή τμήματα βάσεων) χωρίς primary keys, indexes, βάσεις μη κανονικοποιημένες κλπ. Όλα αυτά γίνονται για διάφορους ειδικούς λόγους όπως ευελιξία στο migration δεδομένων, ταχύτητα στην καταχώρηση, διατήρηση ιστορικών δεδομένων, ευκολότερο reporting κλπ. Επίσης τέτοιες βάσεις δεν είναι απαραίτητα transactional. Δεν είναι δηλαδή οι βάσεις που χρησιμοποιούν οι τυπικές εφαρμογές χρηστών που καταχωρούν δεδομένα. Ίσως είναι βάσεις για MIS, Reporting κλπ.

...........Δεν είναι η εμπειρία που τα κάνει να μην χρειάζονται. Είναι η εφαρμογή.

+++10000

Απ: Σχεσιακές βάσεις χωρίς... σχέσεις;

Antonios Chatzipavlis — Fri, 12 Feb 2010 19:51:23 GMT

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

Αλλά ένα θα πω αυτό που έχει πει ένας από του 7 Σοφούς της αρχαιότητας ο Κλεόβουλος από την Λίνδο της Ρόδου.

Ὀψιμανθῆ εἶναι μᾶλλον ἢ ἀμαθῆ.

Αυτό και τίποτα παραπάνω.

Απ: Σχεσιακές βάσεις χωρίς... σχέσεις;

Panagiotis Kefalidis — Fri, 12 Feb 2010 19:35:24 GMT

Σωστά όλα τα παραπάνω, και πολλές φορές σε reporting είναι μονόδρομος. Και συνήθως κάποια crucial/mandatory Keys και constraints εξακολουθούν να υπάρχουν (ώστε να μην μπορείς να τα κάνεις εντελώς κολουβάχατα) αλλά αυτό που πάει περίπατο σχεδόν σίγουρα είναι η κανονικοποίηση.

Πάντως ήταν είναι ένα σενάριο που δεν το είχαμε αναφέρει και έπρεπε να ακουστεί.

Σχεσιακές βάσεις χωρίς... σχέσεις;

Dimitris Papadimitriou — Fri, 12 Feb 2010 18:33:17 GMT

Ξεκίνησε μια ζεστή (για να μην πω καυτή και τσουρουφλιστή) συζήτηση σε άλλο thread σχετικά με την σχεδίαση σχεσιακών βάσεων (κλασικών βάσεων δηλαδή σε sql server, oracle, mysql, access κλπ) που δεν έχουν relationships. Μάλιστα αναφέρθηκε ότι υπάρχουν τέτοια συστήματα από έμπειρους προγραμματιστές. Επίσης αναφέρθηκε από άλλους διαφωνούντες ότι κάτι τέτοιο είναι επικίνδυνο. Να πω 1-2 πράγματα αν μου επιτρέπετε, έστω κι αν είναι προφανή και χωρίς να θέλω να προσθέσω κάτι στα λεγόμενα των υπολοίπων του προηγούμενου thread.

(ΠΡΟΣΟΧΗ! Μην μείνετε μόνο στο 1 - διαβάστε και το 2) Ναι, υπάρχουν βάσεις δεδομένων χωρίς relationships. Ίσως πολλές φορές τμήματα αυτών. Όπως υπάρχουν και βάσεις (ή τμήματα βάσεων) χωρίς primary keys, indexes, βάσεις μη κανονικοποιημένες κλπ. Όλα αυτά γίνονται για διάφορους ειδικούς λόγους όπως ευελιξία στο migration δεδομένων, ταχύτητα στην καταχώρηση, διατήρηση ιστορικών δεδομένων, ευκολότερο reporting κλπ. Επίσης τέτοιες βάσεις δεν είναι απαραίτητα transactional. Δεν είναι δηλαδή οι βάσεις που χρησιμοποιούν οι τυπικές εφαρμογές χρηστών που καταχωρούν δεδομένα. Ίσως είναι βάσεις για MIS, Reporting κλπ.
Κατά αντιστοιχία, υπάρχουν και μηχανές χωρίς φρένα, αυτοκίνητα με 500hp χωρίς ESP κλπ κλπ. Μόνο που αυτά τα οχήματα τα οδηγεί ο Stig και δεν τα αφήνει στον Captain Slow (συνήθως). Επίσης πολλές φορές απαγορεύεται από τον ΚΟΚ να βγουν στους δρόμους (βλ. μηχανές χωρίς φρένα), οπότε ακόμα και ο Stig τα οδηγάει σε ειδικές πίστες. Αυτό που θέλω να πω είναι ότι 95-99% των περιπτώσεων μια βάση και ένας προγραμματιστής (άσχετα με το πόσο έμπειρος είναι) χρειάζεται και τα foreign keys και τα primary keys και τα indexes και την κανονικοποίηση. Δεν είναι η εμπειρία που τα κάνει να μην χρειάζονται. Είναι η εφαρμογή.