Εισαγωγή στις Βάσεις Δεδομένων

Transcript

1 ΔΙΕΚ ΣΥΡΟΥ Ειδικότητα: Τεχνικός Εφαρμογών Πληροφορικής (Πολυμέσα / Web Designer - Developer / Video Games) Μάθημα: Βάσεις Δεδομένων Εισαγωγή στις Βάσεις Δεδομένων Ι. Γαβιώτης, Μηχανικός Η/Υ & Πληροφορικής 1. Εισαγωγή 1.1 Τι είναι ένα σύστημα βάσης δεδομένων Ένα σύστημα βάσης δεδομένων (database system) είναι ένα πληροφοριακό σύστημα το οποίο διαχειρίζεται εγγραφές δεδομένων. Βασικός του σκοπός είναι η καταγραφή και διατήρηση (μεγάλων ποσοτήτων) πληροφοριών. Τα δεδομένα που μπορούν να αποθηκευτούν μπορεί να είναι οποιοδήποτε σημαντικό στοιχείο του οργανισμού που εξυπηρετεί το σύστημα της βάσης δεδομένων, πχ πελάτες, προϊόντα, πωλήσεις. Κατά παράδοση, τα περιεχόμενα μιας ΒΔ είναι δομημένα δεδομένα, δηλαδή οργανωμένα σε γραμμές και στήλες. Το όφελος από τη χρήση μιας ΒΔ προκύπτει όταν τα δεδομένα σχετίζονται μεταξύ τους και από τους συνδυασμούς των συνάγεται χρήσιμη πληροφορία. Γι αυτό θα ασχοληθούμε με τις σχεσιακές βάσεις δεδομένων (relational databases), αν και υπάρχουν και άλλα είδη ή μοντέλα που, ωστόσο, δεν είναι τόσο σημαντικά ή διαδεδομένα. Παραδείγματα Το 1970 ο E. Codd, ερευνητής στην IBM, πρότεινε το σχεσιακό μοντέλο για τις βάσεις δεδομένων, που επικράτησε λόγω της απλότητάς του. Πάνω σε αυτό στηρίχτηκε η γλώσσα SQL που είναι η κοινή γλώσσα όλων των ΣΔΒΔ σήμερα. Μια μικρή βάση δεδομένων για προσωπική χρήση διατηρεί πληροφορίες για τη μουσική συλλογή μας. Μια εμπορική επιχείρηση τηρεί μια βάση δεδομένων με το πελατολόγιό της. Το Υπουργείο Οικονομικών τηρεί σε μια βάση δεδομένων τα οικονομικά στοιχεία των φορολογουμένων της χώρας μας. Ένα σύστημα αρχειοθέτησης είναι μια βάση δεδομένων, ακόμα κι αν δεν είναι σε ηλεκτρονική μορφή. 1.2 Δομικά στοιχεία μιας βάσης δεδομένων Το σύστημα της βάσης δεδομένων αποτελείται από: Δεδομένα (data) Υλικό (hardware) Λογισμικό (software) Χρήστες (users) Δεδομένα Τα δεδομένα του συστήματος μπορούν να αποθηκευτούν σε μία ή περισσότερες βάσεις δεδομένων. Ουσιαστικά μια βάση δεδομένων (ΒΔ) είναι μια συλλογή αποθηκευμένων δεδομένων που χρησιμοποιούνται από διάφορα συστήματα εφαρμογών μιας συγκεκριμένης επιχείρησης. Υλικό Το υλικό αποτελείται από συσκευές αποθήκευσης δεδομένων (όπως δίσκοι, μαγνητικές ταινίες, κ.ά.) πάνω στις οποίες βρίσκεται η βάση δεδομένων και από τις απαραίτητες εκείνες συσκευές για τη λειτουργία του υπολογιστικού συστήματος (όπως μονάδες επεξεργασίας, γραμμές επικοινωνίας, κ.λπ.). Λογισμικό Μεταξύ της φυσικής βάσης δεδομένων (δηλαδή των δεδομένων όπως πραγματικά αποθηκεύονται) και των χρηστών του συστήματος υπάρχει ένα «στρώμα» λογισμικού το οποίο ονομάζεται Σύστημα Διαχείρισης Βάσης Δεδομένων (ΣΔΒΔ, database management system) μέσω του οποίου εξυπηρετούνται όλες οι απαιτήσεις των χρηστών για προσπέλαση στη βάση δεδομένων. Ο χρήστης προσδιορίζει τους χειρισμούς που θέλει να κάνει πάνω στη βάση δεδομένων και το ΣΔΒΔ φροντίζει για την εκτέλεση των απαραίτητων λειτουργιών ώστε να εξυπηρετηθεί η επιθυμία του χρήστη. igaviotis@gmail.com 25-Νοε-16 Σελ. 1

2 Εμείς θα χρησιμοποιήσουμε το ΣΔΒΔ Access της εταιρείας Microsoft που λειτουργεί κάτω από το περιβάλλον των Windows και θα δούμε και τα ΣΔΒΔ SQL Server και MySQL. Άλλα ΣΔΒΔ με σημαντική παρουσία στην αγορά είναι η Oracle, η DB2 και η PostgreSQL. Τα διάφορα ΣΔΒΔ διαφοροποιούνται με βάση την ιδιαίτερη ομάδα στην οποία στοχεύουν, πχ μεγάλες επιχειρήσεις έναντι προσωπικής χρήσης, ελεύθερα έναντι επί πληρωμή, εύχρηστα έναντι σταθερά, κλπ. Στην ιστοσελίδα τα ΣΔΒΔ κατατάσσονται με βάση το πλήθος των τεχνικών ερωτημάτων που υποβάλλονται γι αυτά (δείτε Εικόνα 2). Έχει γίνει προσπάθεια τα παραδείγματα που παρουσιάζονται να μην εκμεταλλεύονται ιδιαίτερες λειτουργίες κάποιου ΣΔΒΔ, άρα να λειτουργούν σε όλα. Όπου υ- πάρχει κάποια ιδιαιτερότητα, σημειώνεται σε ποιο ΣΔΒΔ ανήκει. Χρήστες Σε ένα σύστημα βάσης δεδομένων υπάρχουν τρία είδη χρηστών: Τελικοί χρήστες (end users) Εικόνα 2 Δημοφιλή ΣΔΒΔ που κάνουν εισαγωγή στοιχείων ή παίρνουν πληροφορίες με κάποιον απλό τρόπο χωρίς να έχουν γνώση του συστήματος βάσης δεδομένων. Προγραμματιστές που γράφουν προγράμματα εφαρμογών σε κάποια γλώσσα προγραμματισμού (PHP, JavaScript, C, SQL, κ.ά.) και τα οποία χρησιμοποιούν τη βάση δεδομένων. Διαχειριστής (database administrator) ο οποίος γνωρίζει τα πάντα γύρω από το σύστημα και τον υπολογιστή που είναι υλοποιημένο και είναι υπεύθυνος για την καλή λειτουργία και τη συντήρησή του. 1.3 Τι χρειάζονται οι βάσεις δεδομένων Εικόνα 1 Λογότυπα των πιο διαδεδομένων ΣΔΒΔ Γιατί να μην χρησιμοποιήσει κάποιος έναν πίνακα του Word ή ένα φύλλο του Excel, με τα οποία είναι και περισσότερο εξοικειωμένος; Πράγματι οι πληροφορίες μιας ΒΔ είναι οργανωμένες σε πίνακες με γραμμές και στήλες, όπως και σε ένα κειμενογράφο που μάλιστα μπορούμε να περιποιηθούμε περισσότερο την εμφάνιση των δεδομένων. Ωστόσο, η ΒΔ επιτρέπει μαζικές ενημερώσεις, πράξεις ομαδοποίησης των δεδομένων, αυτόματη αποθήκευση ανά εγγραφή, επιβολή κανόνων για τα περιεχόμενα των κελιών. Ένα λογιστικό φύλλο υποστηρίζει αρκετές από αυτές τις λειτουργίες, αλλά η βασική διαφορά της ΒΔ είναι ότι επιτρέπει τη συσχέτιση των δεδομένων από διαφορετικούς πίνακες. Για παράδειγμα, σε ένα φύλλο του Excel μπορούμε να έχουμε τους πελάτες και σε ένα άλλο τις παραγγελίες, αλλά δεν γίνεται να τα συσχετίσουμε. Οι βάσεις δεδομένων είναι απαραίτητες όταν συσσωρεύεται μεγάλος όγκος δεδομένων που πρέπει να συνδυαστούν μεταξύ τους και να τύχουν επεξεργασίας για να γίνουν χρήσιμη πληροφορία. Συνήθως τα δεδομένα αυτά εξελίσσονται στο χρόνο και πρέπει να διατηρούνται ενημερωμένα, ενώ σε μερικές περιπτώσεις πρέπει να διατηρείται και το ιστορικό των αλλαγών τους. Το σύστημα πρέπει να είναι αξιόπιστο, δηλαδή να παρέχει ανά πάσα στιγμή ορθά και συνεπή δεδομένα και να είναι διαθέσιμο χωρίς διαλείψεις. Ανάλογα με την περίπτωση μπορεί να απαιτείται να υποστηρίζει ταυτόχρονη πρόσβαση και ενημέρωση από πολλούς χρήστες 1. 1 Αυτές οι απαιτήσεις αναφέρονται συνολικά ως ACID (Atomicity, Consistency, Isolation, Durability). Ατομικότητα σημαίνει ότι μια λειτουργία ή ολοκληρώνεται πλήρως ή αποτυγχάνει ολοκληρωτικά-δεν μπορεί να μείνει στα μισά. Συνέπεια σημαίνει ότι οι κανόνες ακεραιότητας δεδομένων ισχύουν αδιαλείπτως. Απομόνωση σημαίνει ότι παράλληλα εξελισσόμενες λειτουργίες είναι αόρατες μεταξύ τους. Μονιμότητα σημαίνει ότι τα αποτελέσματα των ολοκληρωμένων λειτουργιών δεν χάνονται. igaviotis@gmail.com 25-Νοε-16 Σελ. 2

3 1.4 Βασικές έννοιες Σε μια ΒΔ η βασική οντότητα είναι ο πίνακας (table) που ομαδοποιεί πληροφορίες ίδιου τύπου. Για παράδειγμα, σε μια ΒΔ για μια βιβλιοθήκη (στη ΒΔ ) διακρίνουμε τους πίνακες ΑΝΘΡΩΠΟΙ και ΒΙΒΛΙΑ. Στο ΣΔΒΔ Access μια ΒΔ αποθηκεύεται σε ένα αρχείο του υπολογιστή, με κατάληξη.accdb. Μέσα σε αυτό το αρχείο αποθηκεύονται όλα τα δεδομένα στους πίνακες, καθώς και ό,τι άλλο έχει σχέση με τη συγκεκριμένη ΒΔ. Εγγραφή (record) ενός πίνακα ονομάζουμε το σύνολο των πληροφοριών που έχουμε για κάθε στοιχείο του πίνακα. Οι πίνακες μπορούν να έχουν μεγάλο αριθμό εγγραφών, χιλιάδες ή και εκατομμύρια. Τυπικά κάθε εγγραφή του πίνακα αντιστοιχεί σε μια γραμμή. Πεδίο (field) ονομάζουμε τη μικρότερη μονάδα αποθήκευσης δεδομένων. Στον πίνακα ΑΝΘΡΩΠΟΙ, το ΕΠΩΝΥΜΟ είναι ένα πεδίο. Τυπικά, κάθε πεδίο ενός πίνακα αντιστοιχεί σε μια στήλη του. Για κάθε πεδίο πρέπει να καθορίσουμε τι είδους τιμές μπορεί να παίρνει, π.χ. αριθμητικές, κειμένου, κά. Αυτοί ονομάζονται τύποι δεδομένων (data types) και οι πιο συνηθισμένοι είναι ακέραιοι (INT), πραγματικοί (REAL), κειμένου (TEXT), ημερομηνίας (DATE). Κλειδί (key), ή πρωτεύον κλειδί ονομάζουμε εκείνο το πεδίο ή τον συνδυασμό πεδίων που χαρακτηρίζουν με μοναδικό τρόπο τις εγγραφές του πίνακα. Δηλαδή, απαγορεύεται να υπάρξουν δυο εγγραφές με το ίδιο κλειδί. Στον πίνακα ΑΝΘΡΩΠΟΙ, κλειδί μπορεί να είναι το ονοματεπώνυμο. Επειδή όμως υπάρχουν συνωνυμίες, προτιμούμε να δίνουμε στους ανθρώπους έναν αριθμό μητρώου που είναι μοναδικός και λειτουργεί ως κλειδί. Ανάλογα κλειδιά σε άλλους πίνακες είναι ο ΑΦΜ για το αρχείο των φορολογουμένων, ο ΑΔΤ, ο αριθμός λογαριασμού στην τράπεζα, κά. Υποχρεωτικά, όλες οι εγγραφές του πίνακα πρέπει να έχουν τιμή στο πρωτεύον τους κλειδί δεν επιτρέπονται τα κενά (null). Κανόνας ακεραιότητας (validation rule) είναι ένας κανόνας που επιβάλλεται στα δεδομένα. Δεδομένα που παραβαίνουν τον κανόνα δεν επιτρέπεται καν να εισαχθούν στον πίνακα. Για παράδειγμα, το πεδίο ΑΡ_ΠΑΙΔΙΩΝ δεν μπορεί να είναι αρνητικό, το πεδίο ΥΨΟΣ πρέπει να είναι μεταξύ 1.20 και 2.60 μέτρων. 2. Σχεδίαση ΒΔ Όσο καλύτερα οργανωμένοι είναι οι πίνακες μιας βάσης δεδομένων, τόσο πιο εύκολα μπορούμε να τη διαχειριστούμε όταν φτάσουμε στο σημείο να απαντηθούν τα διάφορα ερωτήματα που προσδοκούμε από αυτήν. Ακριβώς για το λόγο αυτό θα πρέπει να είμαστε πολύ προσεκτικοί στη σχεδίαση της ΒΔ και ακόμη περισσότερο όταν ορίζουμε τις σχέσεις μεταξύ των διαφόρων πινάκων. 2.1 Σχέση ένα-προς-πολλά Ένα από τα προβλήματα που συνήθως παρουσιάζονται όταν σχεδιάζουμε μια ΒΔ είναι το πρόβλημα των επαναλαμβανόμενων πεδίων. Θέλουμε να δημιουργήσουμε ένα διευθυνσιογράφο (στη ΒΔ ), δηλαδή μια εφαρμογή όπου θα αποθηκεύουμε και θα ανευρίσκουμε ονόματα, διευθύνσεις και τηλέφωνα φίλων μας. Κάθε εγγραφή περιέχει τις πληροφορίες: ονοματεπώνυμο, διεύθυνση, ημερομηνία γέννησης, οικογενειακή κατάσταση, και τηλέφωνα. Τις περισσότερες φορές δεν υπάρχει μόνο ένα τηλέφωνο που αντιστοιχεί σε ένα άτομο (άσε που μερικά άτομα δεν έχουν καθόλου τηλέφωνο). Συνήθως έχουμε τουλάχιστον το τηλέφωνο στη δουλειά, στο σπίτι και το κινητό. Πρώτη προσέγγιση Θα μπορούσαμε να λύσουμε (με ακατάλληλο τρόπο) το πρόβλημα θέτοντας και άλλα πεδία στην εγγραφή του κάθε ανθρώπου που να περιγράφουν και άλλα τηλέφωνα (ΤΗΛ2, ΤΗΛ3, κ.ο.κ.). Ποια μειονεκτήματα διακρίνετε; Είναι φανερό πως αν έχουμε άτομα με τα οποία μπορούμε να έρθουμε σε επικοινωνία μέσω 8 τηλεφωνικών αριθμών και άλλα μέσω μόνον 2 θα έχω αρκετά συχνά άδεια πεδία μέσα στις διάφορες εγγραφές. Ο παρακάτω πίνακας περιγράφει αυτήν την κατάσταση. ΕΠΩΝΥΜΟ ΟΝΟΜΑ ΔΣΗ ΤΚ ΗΜ_ΓΕΝ ΠΑΝΤΡ ΤΗΛ1 ΤΗΛ2 ΤΗΛ3 Λιάνης Νίκος Ανταίου /01/56 Ναι Νέτου Λίνα Ερμού /11/76 Όχι Δεύτερη προσέγγιση Χρησιμοποιώντας μόνο ένα πεδίο για το τηλέφωνο, δημιουργώ πολλαπλές εγγραφές για τα άτομα που έχουν περισσότερα του ενός τηλεφώνου όπου όλα τα υπόλοιπα στοιχεία παραμένουν ως έχουν. Δηλαδή, αν ένας άνθρωπος έχει 6 διαφορετικά τηλέφωνα μέσω των οποίων μπορώ να έρθω σε επικοινωνία μαζί του δημιουργώ 6 εγγραφές οι οποίες θα πρέπει να διαφέρουν μόνο στον αριθμό τηλεφώνου. Ο διπλανός πίνακας περιγράφει αυτήν την κατάσταση. Στην περίπτωση που θελήσω να αλλάξω το περιεχόμενο ενός ή περισσοτέρων από αυτά τα πεδία (π.χ. τη διεύθυνση ή την οικογενειακή κατά- ΕΠΩΝΥΜΟ ΟΝΟΜΑ ΔΣΗ ΤΚ ΗΜ_ΓΕΝ ΠΑΝΤΡ ΤΗΛ Λιάνης Νίκος Ανταίου /01/56 Ναι Λιάνης Νίκος Ανταίου /01/56 Ναι Λιάνης Νίκος Ανταίου /01/56 Ναι Νέτου Λίνα Ερμού /11/76 Όχι igaviotis@gmail.com 25-Νοε-16 Σελ. 3

4 σταση) θα υπάρχει ο κίνδυνος σε άλλες εγγραφές να έχει γίνει η αλλαγή ενώ σε άλλες όχι. Αυτό είναι το πρόβλημα της ασυνέπειας των εγγραφών. Τρίτη προσέγγιση Αναλογιζόμενος πως το τηλέφωνο δεν είναι ένα χαρακτηριστικό του ανθρώπου (αφού μπορεί να έχει πολλά διαφορετικά τηλέφωνα ή και κανένα τηλέφωνο), αποφασίζω ότι είναι καλύτερο να «σπάσω» την πληροφορία που μέχρι τώρα θεωρώ ενιαίο πίνακα. Έτσι δημιουργώ έναν πίνακα με το όνομα ΑΝΘΡΩΠΟΙ. Κλειδί του πίνακα είναι ένας (αυθαίρετος) αριθμός. Σε ένα δεύτερο πίνακα, ΤΗΛΕΦΩΝΑ διατηρώ τις πληροφορίες της τηλεφωνικής σύνδεσης. Με δεδομένο ότι ένας άνθρωπος μπορεί να έχει πολλά τηλέφωνα, αλλά κάθε τηλέφωνο ανήκει σε έναν και μόνο άνθρωπο (δεν επιτρέπονται συνδικαιούχοι), η σχέση των πινάκων ΑΝΘΡΩΠΟΙ και ΤΗΛΕΦΩΝΑ είναι ένα-προςπολλά (one-to-many). Για να συσχετίσουμε τους δύο πίνακες χρησιμοποιούμε την τιμή του κλειδιού του πρωτεύοντα πίνακα ΑΡ_ΑΝΘΡ μέσα στον πίνακα ΤΗΛΕ- ΦΩΝΑ, ονομάζοντάς το ΚΑΤΟΧΟΣ. Υποχρεωτικά τα πεδία ΑΡ_ΜΗΤΡ και ΚΑΤΟΧΟΣ πρέπει να έχουν τον ίδιο τύπο δεδομένων. Προσοχή, το ΚΑΤΟΧΟΣ δεν είναι κλειδί του πίνακα ΤΗΛΕΦΩΝΑ. Στη γραμμή που απεικονίζει τη σχέση παρατηρήστε το σύμβολο (άπειρο, στα μαθηματικά) που υποδεικνύει τα «πολλά» στη σχέση. Το πεδίο ΚΑΤΟΧΟΣ ονομάζεται ξένο κλειδί (foreign key) στον πίνακα ΤΗΛΕΦΩΝΑ, επειδή παραπέμπει σε μια (μοναδική) εγγραφή ενός άλλου πίνακα 2. Ερωτήσεις (Αληθές/Ψευδές): Το ξένο κλειδί πρέπει να είναι του ίδιου τύπου με το πρωτεύον κλειδί του σχετιζόμενου πίνακα. Ένας πίνακας μπορεί να έχει πολλά ξένα κλειδιά. Ένα ξένο κλειδί αποτελείται από ένα πεδίο. Το ξένο κλειδί ενός πίνακα μπορεί να είναι και πρωτεύον κλειδί του. 2.2 Σχέση πολλά-προς-πολλά Οι σχέσεις μεταξύ οντοτήτων μιας ΒΔ μπορούν να είναι ένα-προς-πολλά ή πολλά-προς-πολλά. Ας δούμε ένα παράδειγμα για τη δεύτερη περίπτωση. Θέλουμε να τηρούμε στοιχεία χρήσιμα για τη λειτουργία ενός συνεργείου αυτοκινήτων (στη ΒΔ ). Οι βασικές πληροφορίες που μας ενδιαφέρουν είναι οι εργαζόμενοι που εκτελούν τις εργασίες, τα οχήματα που έρχονται στο συνεργείο για επισκευή και οι εργασίες που εκτελούνται πάνω στα οχήματα από τους εργαζόμενους. Κατά την πλήρη λειτουργία της ΒΔ που θα σχεδιάσουμε οι κύριοι στόχοι είναι: να γνωρίζουμε ποιος εργαζόμενος εργάστηκε σε ποιο όχημα πόσες ώρες, να μπορούμε να κοστολογήσουμε μια εργασία στο σύνολό της αθροίζοντας τις ώρες των εργαζομένων που δούλεψαν σε αυτήν, να μπορούμε να πληρώσουμε τους εργαζόμενους με βάση τις ώρες εργασίας, και να δούμε ποιοι εργαζόμενοι δουλεύουν περισσότερο. Ξεκινούμε δημιουργώντας τους βασικούς πίνακες, ΕΡΓΑΖΟΜΕΝΟΙ και ΟΧΗΜΑΤΑ, στους οποίους θα αποθηκεύσουμε τα δεδομένα που είναι απαραίτητα για τη λειτουργία του συνεργείου. Στον πίνακα ΕΡΓΑΖΟΜΕΝΟΙ, κλειδί είναι ο αριθμός μητρώου (ΑΜ) 15 Λαζόπουλος Λάκης 11,45 και στον πίνακα ΟΧΗΜΑΤΑ ο αύξων αριθμός εισόδου του οχήματος στο συνεργείο. Πίνακας ΕΡΓΑΖΟΜΕΝΟΙ Έχει μείνει σε εκκρεμότητα η πληροφορία ποιος εργαζόμενος εργάστηκε πόσες ώρες σε ποιο όχημα. Έχοντας στο μυαλό ότι σε κάθε όχημα μπορεί να απασχοληθούν πολλοί εργαζόμενοι και βέβαια κάθε εργαζόμενος απασχολείται σε διάφορα οχήματα προκύπτει ότι έχουμε μια σχέση πολλά-προς-πολλά (many-to-many). Άρα θα φτιάξουμε ΑΜ ΑΡ_ΕΙΣ ΗΜ_ΕΡΓΑΣ ΑΠΑΣΧ έναν πίνακα /1/2012 2,5 ΧΡΕΩΣΕΙΣ που θα έχει πεδία τα /1/2012 5,5 κλειδιά των /1/2012 8,0 πινάκων που /1/2012 4, /1/1996 1,5 Πίνακας ΧΡΕΩΣΕΙΣ ΑΜ ΕΠΩΝΥΜΟ ΟΝΟΜΑ ΩΡΟΜΙΣΘΙΟ 12 Βουτσάς Κώστας 10,00 67 Καρακατσάνης Θύμιος 7,50 ΑΡ_ΕΙΣ ΑΡ_ΚΥΚΛΟΦ ΗΜΝΙΑ_ΕΙΣΑΓ 1 ΕΜΑ /1/ ΕΜΑ /1/ ΕΜΝ /1/2012 Πίνακας ΟΧΗΜΑΤΑ συσχετίζει (ΕΡΓΑΖΟΜΕΝΟΙ και ΟΧΗΜΑΤΑ), και ό,τι επιπρόσθετη πληροφορία απαιτείται για τις χρεώσεις, όπως η ημερομηνία που εκτελέστηκε η εργασία και ο χρόνος απασχόλησης σε ώρες. 2 Όπου αναφέρεται σκέτος ο όρος κλειδί, σημαίνει πρωτεύον κλειδί. Το ξένο κλειδί δεν πρέπει να συγχέεται με τα υποψήφια (candidate key) ή τα δευτερεύοντα κλειδιά (secondary key). igaviotis@gmail.com 25-Νοε-16 Σελ. 4

5 Οι περιορισμοί ακεραιότητας θα επιβάλουν ότι η ΒΔ δεν θα έχει πληροφορίες-σκουπίδια από τους απρόσεκτους χρήστες της. Οι κανόνες περιορίζουν το εύρος των νόμιμων τιμών σε συγκεκριμένα όρια, π.χ. ωρομίσθιο >0, επώνυμο NOT IS NULL. 2.3 Ανακεφαλαίωση Σε γενικές γραμμές μπορούμε να διακρίνουμε τις εξής περιπτώσεις όταν οργανώνουμε μια βάση δεδομένων σε ότι αφορά τις σχέσεις μεταξύ οντοτήτων. Σχέση ένα-προς-πολλά Μια εγγραφή συνδέεται με πολλές άλλες. Τέτοιο παράδειγμα είναι κάθε δίσκος μουσικής με τα τραγούδια που περιέχει (στη ΒΔ ). Από τη μεριά του «ένα» είναι οι δίσκοι και από την μεριά του «πολλά» είναι τα τραγούδια. Ένας δίσκος μπορεί να έχει πολλά (που σημαίνει μηδέν, ένα ή οσαδήποτε) τραγούδια, αλλά κάθε τραγούδι ανήκει αυστηρά σε ένα δίσκο (ούτε κανένα, ούτε πολλούς). Στην περίπτωση αυτή πρέπει να διασπάσω την πληροφορία σε δυο πίνακες, όπου ο ένας θα περιέχει τα στοιχεία που αφορούν το δίσκο (π.χ. αριθμό, εταιρεία παραγωγής, έτος κυκλοφορίας, κτλ), ενώ ο δεύτερος θα περιέχει τα στοιχεία που αφορούν τα τραγούδια (π.χ. αύξοντα αριθμό μέσα στο δίσκο, συνθέτη, στιχουργό, κτλ). Όλα τα ΣΔΒΔ δίνουν τη δυνατότητα να επιβάλλονται τέτοιοι κανόνες ακεραιότητας που προσδιορίζουν τη σχέση πινάκων της ΒΔ με κάποιο συνδετικό πεδίο. Στην Access αυτό γίνεται ενεργοποιώντας τον διακόπτη «Ενεργοποίηση ακεραιότητας αναφορών» (Enforce Referential Integrity). Με αυτόν τον τρόπο η ΒΔ δεν πρόκειται να επιτρέψει να εισαχθεί τραγούδι κάποιου ανύπαρκτου δίσκου, ούτε και να διαγραφεί δίσκος αν υπάρχουν τραγούδια που σχετίζονται με αυτόν. Επιπρόσθετα, με το διακόπτη «Διαδοχική ενημέρωση» (Cascade update) εξασφαλίζεται πως αν αλλάξει ο κωδικός του δίσκου, αυτόματα θα ενημερωθεί για την αλλαγή η τιμή του αντίστοιχου πεδίου (ΣΤΟ_ΔΙΣΚΟ) στον πίνακα των τραγουδιών. Ενεργοποιώντας το διακόπτη «Διαδοχική διαγραφή» (Cascade Delete) εξασφαλίζεται πως αν διαγραφεί ένας δίσκος θα Εικόνα 3 Δήλωση σχέσης πινάκων διαγραφούν και όλα τα τραγούδια του. Σχέση πολλά-προς-πολλά Αυτή είναι και η πιο γενική περίπτωση. Μια οντότητα τύπου Α συνδέεται με πολλές άλλες τύπου Β, και αντίστροφα μια οντότητα τύπου Β μπορεί να συνδέεται με πολλές οντότητες τύπου Α 3. Στην περίπτωση αυτή είναι απαραίτητο να δημιουργώ τρίτο πίνακα Γ που να συνδέει τα κλειδιά των δυο πινάκων Α και Β. Για παράδειγμα, ας θεωρήσω στο προηγούμενο παράδειγμα ότι το ίδιο τραγούδι μπορεί να ανήκει σε πολλούς δίσκους, γιατί ο καλλιτέχνης αποφάσισε να το συμπεριλάβει σε μια συλλογή «Τα καλύτερα του». Τότε η σχέση των πινάκων ΔΙΣΚΟΙ και ΤΡΑΓΟΥΔΙΑ2 γίνεται πολλά-προς-πολλά. Σε αυτή την περίπτωση χρειάζεται ένας τρίτος πίνακας (ΣΥΜΜΕΤΟΧΕΣ) που συνδέει τα κλειδιά των δυο πινάκων. Εξηγήστε γιατί το πεδίο ΣΕΙ- ΡΑ_ΣΤΟ_ΔΙΣΚΟ ανήκει στον πίνακα ΣΥΜΜΕΤΟΧΕΣ και όχι στον πίνακα ΤΡΑΓΟΥΔΙΑ2. Η ΒΔ όπως σχεδιάστηκε τώρα, επιτρέπει στο ίδιο τραγούδι να εμφανίζεται στον ίδιο δίσκο δυο φορές; Το γενικό συμπέρασμα είναι ότι η υλοποίηση μιας βάσης δεδομένων γίνεται ευκολότερη όταν έχει προηγηθεί ένας ορθός και λεπτομερής σχεδιασμός. Στο στάδιο του σχεδιασμού πρέπει να καθορίσουμε και τους κανόνες ακεραιότητας που πρέπει να ακολουθούν τα δεδομένα που θα ανήκουν στη βάση. Είπαμε πρωτύτερα ότι η διάρκεια ενός τραγουδιού δεν μπορεί να είναι αρνητική. Επίσης, μπορούμε να πούμε ότι κάθε δίσκος πρέπει να έχει τουλάχιστον ένα τραγούδι και δεν μπορεί να έχει περισσότερα από, π.χ. 30 τραγούδια. Όσο πιο αυστηρούς κανόνες βάλουμε στη σχεδία- 3 Υπενθυμίζεται ότι το «πολλές» σημαίνει μηδέν, μία ή οσεσδήποτε. igaviotis@gmail.com 25-Νοε-16 Σελ. 5

6 ση, τόσο πιο λίγους ελέγχους θα έχουμε να κάνουμε κατά την εισαγωγή των δεδομένων και τόσο λιγότερα σκουπίδια θα μπουν στο πληροφοριακό σύστημα κατά την παραγωγική λειτουργία του. Μην ξεχνάτε ότι η κατασκευή μιας βάσης διαρκεί λίγους μήνες, ενώ μπορεί να χρησιμοποιείται επί χρόνια. Μικρή επιβάρυνση για τον διαχειριστή της ΒΔ, μπορεί να γλυτώσει πολλή δουλειά από τον προγραμματιστή των εφαρμογών και πολλά σφάλματα από την επιχείρηση. 3. Παραδείγματα Ασκήσεις στη σχεδίαση 3.1 Μαγειρική Η κυρία Αντωνία είναι καλή μαγείρισσα και φημίζεται για την ποικιλία των φαγητών που ξέρει να φτιάχνει. Για κάθε συνταγή μαγειρικής, εκτός από το όνομά της, γνωρίζει τον σεφ που τη δημιούργησε, τον χρόνο προετοιμασίας (σε λεπτά), τον τρόπο μαγειρέματος (πχ ψήσιμο, βράσιμο, τηγάνισμα, φούρνισμα), πόσες μερίδες βγάζει, και αν είναι υγιεινή και βέβαια τα υλικά που απαιτεί. Για κάθε υλικό θυμάται, εκτός από όνομά του, την ποσότητα που βάζει, την μονάδα που μετράει την ποσότητα (γραμμάρια, πρέζα, μιλιλίτρα). Επέκταση: Αφού χρησιμοποίησε αρκετό καιρό με μεγάλη επιτυχία το παραπάνω πρόγραμμα και κατέγραψε κάμποσες συνταγές, τώρα θέλει να διατηρεί ένα ιστορικό με τα μαγειρέματα που έχει κάνει. Συγκεκριμένα, κάθε φορά που φτιάχνει μια συνταγή, θέλει να διατηρεί την ημερομηνία παρασκευής της, πόσο της κόστισαν τα υλικά, μια συνολική εκτίμηση για το αποτέλεσμα (κακό - καλό - υπέροχο, κτλ), και τέλος προτάσεις για τη βελτίωση της συνταγής. Δείτε Εικόνα 4 μια σχεδίαση για τη ΒΔ. Δείτε στην ενότητα 6.4 για μια υλοποίηση της ΒΔ. 3.2 Οργάνωση ΙΕΚ Σχεδιάστε μια ΒΔ που θα αναφέρεται στην οργάνωση του Ι.Ε.Κ. σε ότι αφορά μαθήματα, μαθητές και καθηγητές. Σκοπός της θα είναι να μπορεί να καταδείξει ποια μαθήματα διδάσκει κάθε καθηγητής, ποια μαθήματα παρακολουθεί κάθε μαθητής και συνακόλουθα σε ποιους μαθητές διδάσκει κάθε καθηγητής. Αυτό που πρέπει να γίνει πάνω από όλα κατανοητό είναι ότι στο σχεδιασμό μιας βάσης δεδομένων πρέπει να λαμβάνουμε υπόψη, πριν ξεκινήσουμε καν το σχεδιασμό: 1. Τι ακριβώς εξυπηρετεί η βάση δεδομένων και ποιος είναι αυτός που θα την χρησιμοποιεί. 2. Τι είδους πληροφορίες θα αποθηκεύονται σε αυτήν. 3. Ποιοι είναι οι συσχετισμοί μεταξύ των πληροφοριών αυτών. 4. Τι λειτουργίες πρέπει να εκτελεί η βάση. Στόχοι της σχεδίασης είναι οι πίνακες να περιλαμβάνουν μόνο τις πληροφορίες που είναι σχετικές με τις οντότητες που μοντελοποιούν, οι συσχετίσεις να απεικονίζουν σωστά τις σχέσεις ένα-προς-πολλά και πολλά-προς-πολλά ανάμεσα στους πίνακες και να μην υπάρχει επαναλαμβανόμενη πληροφορία. 3.3 Διαδικασία σχεδίασης ΒΔ Εικόνα 4 Σχεδίαση της ΒΔ για συνταγές μαγειρικής Προσπαθήστε να αναγνωρίσετε τις συσχετίσεις που ισχύουν και να κάνετε τον κατάλληλο σχεδιασμό βάσεων δεδομένων για τις παρακάτω περιπτώσεις. Ζευγάρια παντρεμένων ανθρώπων Κρατάει την πληροφορία ποιος είναι σύζυγος ποιας. Συλλογή γραμματοσήμων Ένας συλλέκτης έχει γραμματόσημα από πολλές χώρες του κόσμου και τον ενδιαφέρει για κάθε χώρα να ξέρει σε ποια ήπειρο βρίσκεται και τι νόμισμα έχει. Για τα γραμματόσημα της συλλογής χρειάζεται η ονομαστική τους αξία (που είναι τυπωμένη πάνω στο γραμματόσημο) και η συλλεκτική του αξία (σε ευρώ), το έτος κυκλοφορίας, τα αντίτυπα. Οργάνωση δεξίωσης Κατά την οργάνωση μιας δεξίωσης αποστέλλονται προσκλήσεις στους καλεσμένους οι οποίοι πρέπει να απαντήσουν αν θα παρευρεθούν. Για αυτούς που αποδέχονται την πρόσκληση, δεσμεύεται θέση σε τραπέζι. Για κάθε αίθουσα έχει καταγραφεί ποια τραπέζια έχει και για κάθε τραπέζι πόσες θέσεις υπάρχουν. Απόγονοι Κρατάει τα στοιχεία των γονέων και των παιδιών τους και επίσης ποιος είναι παιδί ποιου. ΚΤΕΟ Καταγράφονται τα αυτοκίνητα που έρχονται για τεχνικό έλεγχο και η πιστοποίηση που λαμβάνουν. Πρέπει να παρακολουθεί πότε έγιναν οι περασμένοι έλεγχοι και να ανακοινώνει την απώτατη ημερομηνία του επόμενου ελέγχου. Ωρομίσθιοι Εργαζόμενοι που ασχολούνται σε τεχνικά έργα αμείβονται ο καθένας με συγκεκριμένο ωρομίσθιο. Καταγράφεται η ώρα προσέλευσης και αποχώρησης για κάθε ημέρα και πρέπει να υπολογίζεται η μηνιαία αμοιβή. igaviotis@gmail.com 25-Νοε-16 Σελ. 6

7 Ασφάλιση οχημάτων Κρατάει την πληροφορία για οχήματα (αυτοκίνητα, μοτοσυκλέτες) που είναι ασφαλισμένα σε διάφορες ασφαλιστικές εταιρίες και οι ιδιοκτήτες τους πληρώνουν τα ασφάλιστρα. Η διαδικασία για να κάνετε την άσκηση αυτή είναι: να καταλάβετε την κάθε περίπτωση σε βάθος, να σκεφτείτε όλες τις περιπτώσεις που μπορούν να υπάρχουν, να εντοπίσετε τις βασικές οντότητες που θα γίνουν αμέσως πίνακες, να προσδιορίσετε τα πεδία τους, να προσδιορίσετε τα κλειδιά τους. Σε δεύτερη φάση: να εντοπίσετε τις συσχετίσεις μεταξύ των βασικών οντοτήτων, να προσδιορίσετε τι τύπου είναι (από τους τρεις που είπαμε παραπάνω) και να φτιάξετε τους κατάλληλους πίνακες που θα αποθηκεύουν τις πληροφορίες συσχέτισης. 3.4 Ποτά και ξενύχτια Σε μια περιοχή λειτουργούν διάφορα μπαρ στα οποία συχνάζουν διάφοροι θαμώνες που πίνουν το αγαπημένο τους ποτό. Θέλουμε να περιγράψουμε τις σχέσεις που υπάρχουν μεταξύ των οντοτήτων Μπαρ, Θαμώνας και Ποτό. Αυτές μπορούμε να τις αποτυπώσουμε σε ένα διάγραμμα, όπου μέσα σε ορθογώνιο σχεδιάζουμε τις οντότητες και τις σχέσεις μεταξύ τους τις απεικονίζουμε με γραμμές που συνδέουν τις οντότητες. Αυτό ονομάζεται διάγραμμα οντοτήτων-σχέσεων (Entity-Relationship diagram). Η σχέση μεταξύ θαμώνα και μπαρ μπορεί να περιγραφεί με το ρήμα «συχνάζει» Θαμώνας Μπαρ και είναι μια σχέση πολλά-προς-πολλά, γιατί ένας άνθρωπος μπο- Συχνάζει ρεί να επισκεφτεί πολλά μπαρ, και βέβαια κάθε μπαρ το επισκέπτονται Πίνει Σερβίρει πολλοί θαμώνες. Η σχέση μεταξύ θαμώνα και ποτού μπορεί να περιγραφεί με το ρήμα «πίνει» και είναι μια σχέση πολλά-προς-πολλά, γιατί ένας άνθρωπος μπορεί να Ποτό Εικόνα 5 Το διάγραμμα της ΒΔ καταναλώσει πολλά και διαφορετικά ποτά σε ένα μπαρ, και βέβαια ένα είδος ποτού το πίνουν πολλοί άνθρωποι. Τέλος, η σχέση μεταξύ μπαρ και ποτού μπορεί να περιγραφεί με το ρήμα «σερβίρει» και είναι πάλι μια σχέση πολλά-προς-πολλά, γιατί ένα μπαρ σερβίρει πολλά και διαφορετικά ποτά, και κάθε ποτό σερβίρεται σε διάφορα μπαρ. Πριν αποφασίσετε αν μια σχέση είναι ένα προς πολλά, πολλά προς πολλά ή ένα προς ένα, θα πρέπει να αναλογίζεστε τη γενικότερη των περιπτώσεων που μπορεί να υπάρξει σε μια σχέση ανάμεσα στις οντότητες που θα διαχειριστείτε. Έτσι, δεν έχει νόημα να «κολλήσετε» στην υπαρκτή μεν, σπάνια δε, περίπτωση που ένα άτομο συχνάζει πάντοτε στο ίδιο μπαρ και πίνει πάντα το ίδιο ποτό. Εσάς σας ενδιαφέρει να οργανώσετε τη βάση δεδομένων σας με τρόπο τέτοιο, ώστε να καλύπτετε όλες τις δυνατές περιπτώσεις που μπορεί να παρουσιαστούν. Και μάλιστα αυτό θα πρέπει να αποτελεί και το πρώτο σας βήμα στο «στήσιμο» της βάσης δεδομένων, πριν ακόμη και από τον καθορισμό των πεδίων που θα περιγράφουν τις οντότητές σας μια και έτσι καθοδηγείστε στην επιλογή των πεδίων και τη δημιουργία των απαραίτητων πινάκων. Μόνο από το παραπάνω διάγραμμα, καταλαβαίνετε πως εκτός από τους βασικούς πίνακες με πιθανή ονομασία ΜΠΑΡ, ΘΑΜΩΝΑΣ και ΠΟΤΟ θα χρειαστεί να δημιουργήσετε άλλους τρεις που ο καθένας θα περιέχει τα κλειδιά δυο από τους βασικούς πίνακες, σύμφωνα με τα όσα έχουμε ήδη αναφέρει. Για εξάσκηση σχεδιάστε τα διαγράμματα οντοτήτων-σχέσεων για τις ΒΔ των παραγράφων 3.1 και 3.3. igaviotis@gmail.com 25-Νοε-16 Σελ. 7

8 4. Ερωτήματα ανάκλησης δεδομένων Σχεδιάσαμε τη ΒΔ και δημιουργήσαμε τους πίνακες και τις σχέσεις τους. Έπειτα αρχίσαμε να εισάγουμε εγγραφές. Τα βήματα αυτά μας οδηγούν σε αλλεπάλληλες τροποποιήσεις με προσθήκη νέων πεδίων, διαμόρφωση των τύπων δεδομένων, εφαρμογή κανόνων ακεραιότητας. Σε αυτή τη φάση είμαστε σε θέση να αντλήσουμε από τη ΒΔ χρήσιμες πληροφορίες. Αυτό γίνεται με τη δημιουργία ερωτημάτων που ανήκουν στη Γλώσσα Ανάκλησης Δεδομένων (Data Query Language). Ένα ερώτημα (query) είναι κώδικας γραμμένος στη γλώσσα SQL που εκτελείται επί των πινάκων της ΒΔ και παράγει αποτελέσματα που έχουν τη μορφή ενός πίνακα. Εναλλακτικά, μπορεί να τροποποιεί τη ΒΔ ενημερώνοντας τα περιεχόμενά της, δεδομένα ή πίνακες. Η γλώσσα SQL (προφέρεται σίκουελ) είναι το διεθνές πρότυπο για τη συγγραφή ερωτημάτων για σχεσιακές βάσεις δεδομένων. Η πιο διαδεδομένη έκδοσή της ονομάζεται ANSI SQL 92 και, παρότι έχει τυποποιηθεί από το διεθνή οργανισμό προτύπων, οι ε- ταιρίες που διαθέτουν ΣΔΒΔ, έχουν παραλλαγές της: PL/SQL (Oracle), T-SQL (Microsoft), κ.λπ. που δυσκολεύουν τη ζωή των διαχειριστών και των προγραμματιστών χωρίς λόγο, αλλά τουλάχιστον δικαιολογούν τους μισθούς τους. Εικόνα 6 Η υλοποίηση των σχέσεων της ΒΔ ΞΕΝΥΧΤΙΑ που περιγράφεται στην ενότητα 3.4. Τη ΒΔ μπο- Τα παραδείγματα ερωτημάτων που θα δούμε εκτελούνται στη ΒΔ ρείτε να τη βρείτε στο Google Drive με μορφή Access. 4.1 Ερωτήματα ταξινόμησης και επιλογής με κριτήρια Θα ξεκινήσουμε με ερωτήματα που επιλέγουν δεδομένα εφαρμόζοντας κριτήρια πάνω στις τιμές των δεδομένων. Συχνά μας ενδιαφέρει να εμφανίσουμε το αποτέλεσμα του ερωτήματος με συγκεκριμένη ταξινόμηση. Για να δούμε όλες τις πληροφορίες των ποτών, γράφουμε: SELECT * FROM ΠΟΤΑ Ο αστερίσκος μετά το SELECT υποδηλώνει όλα τα πεδία. Μπορούμε να τον αντικαταστήσουμε με το όνομα ενός πεδίου, ή με πολλά πεδία χωρισμένα με κόμμα, π.χ. SELECT ΟΝΟ_ΠΟΤ FROM ΠΟΤΑ ή SELECT ΟΝΟ_ΘΑΜ, ΗΛΙΚΙΑ FROM ΘΑΜΩΝΕΣ Για να εφαρμόσουμε ταξινόμηση προσθέτουμε τη φράση ORDER BY με το πεδίο βάσει του οποίου θα γίνει η ταξινόμηση, ακολουθούμενο από ASC για αύξουσα ή DESC για φθίνουσα σειρά. SELECT * FROM ΠΟΤΑ ORDER BY ΑΛΚΟΟΛ DESC Άλλο παράδειγμα: SELECT ΟΝΟ_ΘΑΜ, ΗΛΙΚΙΑ FROM ΘΑΜΩΝΕΣ ORDER BY ΗΛΙΚΙΑ DESC Ταξινόμηση μπορεί να γίνει με πολλά πεδία: SELECT ΟΝΟ_ΘΑΜ, ΗΛΙΚΙΑ FROM ΘΑΜΩΝΕΣ ORDER BY ΗΛΙΚΙΑ DESC, ΟΝΟ_ΘΑΜ ASC Ανακεφαλαιώνοντας τη σύνταξη της εντολής SELECT, όπως την έχουμε δει μέχρι τώρα: SELECT λίστα-πεδίων-που εμφανίζονται FROM πίνακας ORDER BY πεδία-ταξινόμησης igaviotis@gmail.com 25-Νοε-16 Σελ. 8

9 Μέχρι τώρα εμφανίζαμε όλες τις εγγραφές (γραμμές) του πίνακα, άσχετα αν παραλείπαμε μερικά πεδία (στήλες) και εφαρμόζαμε συγκεκριμένη διάταξη με βάση κάποιο πεδίο. Τώρα θα επιλέξουμε μερικές εγγραφές που πληρούν συγκεκριμένα κριτήρια. Αυτό γίνεται με την προσθήκη της φράσης WHERE. Για παράδειγμα, ας επιλέξουμε τους άνδρες θαμώνες: SELECT * FROM ΘΑΜΩΝΕΣ WHERE ΦΥΛΟ = 'Ανδρας' Τα «βαριά» ποτά είναι: SELECT * FROM ΠΟΤΑ ORDER BY ΑΛΚΟΟΛ DESC WHERE ΑΛΚΟΟΛ >= 0.45 Οι νεαρές κυρίες είναι SELECT * FROM ΘΑΜΩΝΕΣ WHERE (ΦΥΛΟ = 'Γυναίκα') AND (ΗΛΙΚΙΑ BETWEEN 25 AND 35) Τα μπαράκια που παίζουν χορευτική μουσική είναι SELECT ΟΝΟ_ΜΠΑΡ, ΜΟΥΣΙΚΗ FROM ΜΠΑΡΑΚΙΑ WHERE ΜΟΥΣΙΚΗ IN ('Dance', 'Techno', 'House') O τελεστής IN στο προηγούμενο παράδειγμα, ψάχνει αν ένα πεδίο έχει κάποια από τις τιμές που απαριθμούνται μέσα στη λίστα με τις παρενθέσεις και χρησιμοποιείται για να αποφύγουμε τα επαναλαμβανόμενα OR μέσα στο WHERE. Για να συνοψίσουμε, η εντολή ανάκλησης δεδομένων SELECT έχει σύνταξη: SELECT λίστα-πεδίων-που εμφανίζονται FROM πίνακας ORDER BY πεδία-ταξινόμησης WHERE κριτήριο Το κριτήριο είναι μια παράσταση με τους τελεστές =,>,<,<=,>= και τις δυαδικές πράξεις AND, OR, NOT. Συχνά χρησιμοποιούμε και τους τελεστές BETWEEN AND για εύρος τιμών, IN για επιλεγμένες τιμές και IS NULL που ανιχνεύει κενές τιμές, όπως εδώ: SELECT * FROM ΘΑΜΩΝΕΣ WHERE ΗΛΙΚΙΑ IS NULL ή εδώ: SELECT ΟΝΟ_ΘΑΜ, ΗΛΙΚΙΑ FROM ΘΑΜΩΝΕΣ WHERE (ΦΥΛΟ IS NOT NULL) AND ((ΗΛΙΚΙΑ BETWEEN 25 AND 35) OR (ΗΛΙΚΙΑ IS NULL)) ORDER BY ΟΝΟ_ΘΑΜ Τέλος, ένας χρήσιμος τελεστής για πεδία κειμένου είναι ο LIKE που ταιριάζει τιμές με ένα πρότυπο που περιλαμβάνει χαρακτήρες πασπαρτού, όπως ο %, που ταιριάζει πολλούς χαρακτήρες 4. Το επόμενο παράδειγμα βρίσκει όλους του θαμώνες που το όνομά τους ξεκινά από «Α». SELECT ΟΝΟ_ΘΑΜ FROM ΘΑΜΩΝΕΣ WHERE ΟΝΟ_ΘΑΜ LIKE 'A%' Για πείτε τώρα, τι νομίζετε ότι κάνει η SELECT ΟΝΟ_ΜΠΑΡ FROM ΜΠΑΡΑΚΙΑ WHERE ΜΟΥΣΙΚΗ NOT LIKE '%Rock%' Εκτός από το χαρακτήρα πασπαρτού %, υπάρχει και ο _ (underscore, υπογράμμιση) που ταιριάζει έναν μοναδικό χαρακτήρα. Για παράδειγμα, η φράση ΠΟΤΟ LIKE '_ola' θα ταιριάσει με τα ποτά 'Cola', 'cola', 'Lola', κ.λπ. 4.2 Υπολογιζόμενα πεδία Τα ερωτήματα που έχουμε δει εδώ εμφανίζουν πληροφορία που ήδη υπάρχει στα πεδία κάποιου πίνακα. Μερικές φορές χρειάζεται να υπολογίσουμε κάποια τιμή και να την εμφανίσουμε στο αποτέλεσμα ενός ερωτήματος. Αυτό γίνεται ορίζοντας ένα υπολογιζόμενο πεδίο (calculated field). Για παράδειγμα, θέλουμε να δούμε ποιο μήνα άνοιξε κάθε μπαρ, ενώ στον πίνακα έχουμε την ημερομηνία των εγκαινίων. Χρησιμοποιούμε τη συνάρτηση Month() που επιστρέφει το μήνα του έτους. SELECT ΟΝΟ_ΜΠΑΡ, Month(ΗΜ_ΑΝΟΙΓΜ) AS ΜΗΝΑΣ FROM ΜΠΑΡΑΚΙΑ 4 Στην Access ο χαρακτήρας πασπαρτού δεν είναι ο %, αλλά ο *. Άρα για το παράδειγμα που ακολουθεί θα έπρεπε να γράψετε ΟΝΟ_ΘΑΜ LIKE 'A*' igaviotis@gmail.com 25-Νοε-16 Σελ. 9

10 Με τη λέξη AS ονοματίζουμε το υπολογιζόμενο πεδίο. Μια χρήσιμη εντολή που μετρά το πλήθος των εγγραφών ενός πίνακα είναι: SELECT Count(*) AS ΠΛΗΘΟΣ_ΜΠΑΡ FROM ΜΠΑΡΑΚΙΑ Τώρα ας κατατάξουμε τα ποτά με βάση την περιεκτικότητά τους σε αλκοόλ σε ελαφρά, που έχουν οινόπνευμα λιγότερο από 15% και στα υπόλοιπα που είναι βαριά. SELECT ΟΝΟ_ΠΟΤ, IIf(ΑΛΚΟΟΛ<0.15, 'Ελαφρύ', 'Βαρύ') AS ΤΥΠΟΣ_ΠΟΤΟΥ FROM ΠΟΤΑ Εδώ το αποτέλεσμα του ερωτήματος έχει δυο στήλες: το όνομα του ποτού και τη στήλη ΤΥΠΟΣ_ΠΟΤΟΥ που έχει τιμή ΕΛΑ- ΦΡΥ για τα ποτά με αλκοόλ λιγότερο του 15% και ΒΑΡΥ για όλα τα υπόλοιπα. (Τι εμφανίζει όταν το ποτό δεν έχει αλκοολικό βαθμό;) Η συνάρτηση IIf() παρότι πολύ χρήσιμη, ανήκει στην SQL εκδοχή της Access. Σε άλλα ΣΔΒΔ υπάρχουν παρόμοιες δομές, όπως η CASE WHEN και η CHOOSE. Το κάθε ΣΔΒΔ παρέχει διάφορες συναρτήσεις (δείτε μερικές στην Εικόνα 7) για υπολογισμούς σε ημερομηνίες, συμβολοσειρές, αριθμητικές πράξεις, κ.λπ., όπως οι Month, Count και IIf που είδαμε στα προηγούμενα παραδείγματα. Σημειώνουμε ότι τα αποτελέσματα των ερωτημάτων δεν αποθηκεύονται πουθενά στη ΒΔ. Υπολογίζονται στιγμιαία κατά την εκτέλεση του ερωτήματος, προβάλλονται στην οθόνη και έπειτα χάνονται αν δεν φροντίσουμε να τα εξάγουμε προς ένα αρχείο. 4.3 Ερωτήματα σύνδεσης πινάκων Συναρτήσεις συμβολοσειρών Left, Right, Mid, Trim, UCase Συναρτήσεις για αριθμούς Abs, Round, Mod Συναρτήσεις για ημερομηνίες Month, Year, DateAdd Εικόνα 7 Συναρτήσεις Όλα τα ερωτήματα που είδαμε στην προηγούμενη παράγραφο αντλούν στοιχεία από ένα πίνακα, του οποίου το όνομα εμφανίζεται στη φράση FROM. Τώρα θα δούμε ερωτήματα που συνδυάζουν στοιχεία δύο ή περισσότερων πινάκων. Ψάχνουμε τις ηλικίες των θαμώνων του κάθε μπαρ. Στον πίνακα ΣΥΧΝΑΖΕΙ υπάρχει η πληροφορία ποιος θαμώνας συχνάζει σε ποιο μπαρ, αλλά η ηλικία είναι πεδίο του πίνακα ΘΑΜΩΝΑΣ. Έτσι χρειαζόμαστε πεδία από δυο πίνακες. Στο ερώτημα σύνδεσης που ακολουθεί χρειάζεται να ορίσουμε τα πεδία με τα οποία σχετίζονται οι εγγραφές από τους δυο πινάκες, όπως φαίνεται και στην Εικόνα 6. Έτσι το ερώτημα γράφεται: SELECT ΜΠΑΡ, ΟΝΟ_ΘΑΜ, ΗΛΙΚΙΑ FROM ΘΑΜΩΝΕΣ INNER JOIN ΣΥΧΝΑΖΕΙ ON ΟΝΟ_ΘΑΜ = ΘΑΜΩΝΑΣ Στη φράση FROM έχουμε τα ονόματα των δυο πινάκων και τα πεδία που τους συνδέουν μεταξύ τους. Το αποτέλεσμα φαίνεται στην Εικόνα 8. Ας προχωρήσουμε σε άλλα παραδείγματα. Τι μουσική παίζουν τα μπαράκια που συχνάζει ο κάθε θαμώνας; SELECT ΘΑΜΩΝΑΣ, ΜΟΥΣΙΚΗ FROM ΣΥΧΝΑΖΕΙ INNER JOIN ΜΠΑΡΑΚΙΑ ON ΜΠΑΡ = ΟΝΟ_ΜΠΑΡ ORDER BY ΘΑΜΩΝΑΣ ASC, ΜΟΥΣΙΚΗ ASC Ποιοι θαμώνες πίνουν μη αλκοολούχα ποτά; SELECT ΘΑΜΩΝΑΣ FROM ΠΙΝΕΙ INNER JOIN ΠΟΤΑ ON ΠΟΤΟ = ΟΝΟ_ΠΟΤ WHERE ALKOOL = 0.00 ORDER BY ΘΑΜΩΝΑΣ ASC Τι μουσική παίζουν τα μπαράκια σε σχέση με την ηλικία των θαμώνων τους; SELECT ΗΛΙΚΙΑ, ΜΟΥΣΙΚΗ FROM ΜΠΑΡΑΚΙΑ INNER JOIN Εικόνα 8 Ερώτημα σύνδεσης (ΘΑΜΩΝΕΣ INNER JOIN ΣΥΧΝΑΖΕΙ ON ΟΝΟ_ΘΑΜ = ΘΑΜΩΝΑΣ) ON ΟΝΟ_ΜΠΑΡ = ΜΠΑΡ ORDER BY ΗΛΙΚΙΑ Εδώ χρειάστηκε να συνδέσουμε τρεις πίνακες, αρχικά τους δύο μεταξύ τους και μετά το αποτέλεσμα της σύνδεσης με τον τρίτο πίνακα. Σε περίπτωση που υπάρχει συνωνυμία σε πεδία των πινάκων που συμμετέχουν σε ερώτημα JOIN, λύνουμε το διφορούμενο προτάσσοντας το όνομα του πίνακα στο όνομα του πεδίου με τελεία ανάμεσα. Για παράδειγμα, το ερώτημα που ακολουθεί επιστρέφει σε ποια μπαρ μπορεί καθένας να βρει κάποιο από τα ποτά που πίνει. SELECT ΜΠΑΡ, ΘΑΜΩΝΑΣ FROM (ΠΟΤΑ INNER JOIN ΠΙΝΕΙ ON ΟΝΟ_ΠΟΤ = ΠΙΝΕΙ.ΠΟΤΟ) INNER JOIN ΣΕΡΒΙΡΕΙ ON ΟΝΟ_ΠΟΤ = ΣΕΡΒΙΡΕΙ.ΠΟΤΟ igaviotis@gmail.com 25-Νοε-16 Σελ. 10

11 Το πεδίο ΠΟΤΟ εμφανίζεται σε δυο πίνακες, γι' αυτό είναι απαραίτητο να αναφέρουμε και τον πίνακα από όπου προέρχεται κάθε φορά που το χρησιμοποιούμε. Η γενική σύνταξη της φράσης FROM στην περίπτωση της σύνδεσης πινάκων είναι: FROM πίνακας1 INNER JOIN πίνακας2 ON πίνακας1.πεδίο1 = πίνακας2.πεδίο2 Ανακεφαλαιώνοντας, τα ερωτήματα σύνδεσης επιλέγουν σχετικές εγγραφές από δύο πίνακες που ταιριάζουν με βάση τις τιμές κάποιων πεδίων από τον καθένα και συνενώνουν τα πεδία αυτών των δύο εγγραφών σε μια γραμμή. Συνήθως, στα ερωτήματα σύνδεσης εμφανίζονται πίνακες που ήδη κατά το σχεδιασμό της ΒΔ συνδέονται με σχέση ξένου κλειδιού, δηλαδή το κλειδί του ενός πίνακα είναι ξένο κλειδί στον άλλο πίνακα 4.4 Πράξεις συνόλων Σε αυτή την ενότητα θα δούμε εντολές της SQL που λειτουργούν όπως οι πράξεις συνόλων ένωση, τομή και αφαίρεση. Για να συμπεριλάβουμε στο αποτέλεσμα τις εγγραφές δυο πινάκων χρησιμοποιούμε τον τελεστή UNION, ως εξής: SELECT * FROM ΠΕΛΑΤΕΣ_ΕΣΩΤ UNION SELECT * FROM ΠΕΛΑΤΕΣ_ΕΞΩΤ Οι δυο παράγοντες που συμμετέχουν στη UNION πρέπει να έχουν τα ίδια πεδία. Σε διαφορετική περίπτωση μπορούμε να επιλέξουμε πεδία: SELECT ΟΝΟΜΑ, ΤΗΛ AS ΤΗΛΕΦΩΝΟ FROM ΠΕΛΑΤΕΣ UNION SELECT ΟΝΟΜΑ, ΦΑΞ AS ΤΗΛΕΦΩΝΟ FROM ΠΡΟΜΗΘΕΥΤΕΣ Η UNION εξ ορισμού κόβει από το αποτέλεσμα τις διπλότυπες εγγραφές, όπως μάθαμε και στη θεωρία συνόλων του Γυμνασίου. Για να έχουμε στο αποτέλεσμα όλες τις εγγραφές των πινάκων που συμμετέχουν, ακόμα και τις διπλότυπες, προσθέτουμε τη φράση ALL. SELECT ΟΝΟΜΑ, ΤΗΛ AS ΤΗΛΕΦΩΝΟ, 'Προμηθευτές' AS ΠΗΓΗ FROM ΠΕΛΑΤΕΣ UNION ALL SELECT ΟΝΟΜΑ, ΦΑΞ AS ΤΗΛΕΦΩΝΟ, 'Πελάτες' AS ΠΗΓΗ FROM ΠΡΟΜΗΘΕΥΤΕΣ Για να ξεχωρίσουμε ποια εγγραφή προήλθε από ποιον πίνακα, προσθέσαμε ένα «υπολογιζόμενο» πεδίο ΠΗΓΗ. Η εντολή INTERSECT υλοποιεί την τομή συνόλων, δηλαδή στο αποτέλεσμα της SELECT ΟΝΟΜΑ FROM ΠΡΟΜΗΘΕΥΤΕΣ WHERE ΠΕΡΙΟΧΗ = 'Κρήτη' INTERSECT SELECT ΟΝΟΜΑ FROM ΠΕΛΑΤΕΣ WHERE ΠΕΡΙΟΧΗ = 'Κρήτη' θα υπάρχουν τα ονόματα των συνεργατών μας στην Κρήτη από τους οποίους αγοράζουμε και πουλάμε προϊόντα. Τέλος η εντολή EXCEPT υλοποιεί την αφαίρεση συνόλων, δηλαδή στο αποτέλεσμα της SELECT ΟΝΟΜΑ FROM ΦΙΛΟΙ EXCEPT SELECT ΟΝΟΜΑ FROM ΣΥΓΓΕΝΕΙΣ θα εμφανίζονται όλοι οι φίλοι που δεν είναι συγγενείς. 4.5 Ερωτήματα ομαδοποίησης εγγραφών Εικόνα 9 Διαγράμματα για UNION, INTERSECT, EXCEPT Μέχρι τώρα ασχοληθήκαμε με ερωτήματα που ανασύρουν αναλυτικά όλες τις εγγραφές που ταιριάζουν με τα κριτήρια επιλογής και σύνδεσης. Τώρα θα ασχοληθούμε με ερωτήματα που ομαδοποιούν τα δεδομένα εγγραφών, εκτελώντας μια πράξη, όπως καταμέτρηση πλήθους, υπολογισμός αθροίσματος, μικρότερης ή μεγαλύτερης τιμής. Αυτή η λειτουργία γίνεται με χρήση της φράσης GROUP BY. Ας δούμε τι είδη μουσικής παίζονται από τα μπαράκια: SELECT ΜΟΥΣΙΚΗ FROM ΜΠΑΡΑΚΙΑ GROUP BY ΜΟΥΣΙΚΗ Ας μετρήσουμε πόσοι θαμώνες είναι άνδρες και πόσες γυναίκες: SELECT ΦΥΛΟ, Count(ΟΝΟ_ΘΑΜ) AS ΠΟΣΟΙ_ΕΙΝΑΙ FROM ΘΑΜΩΝΕΣ GROUP BY ΦΥΛΟ Η φράση GROUP BY λέει με ποιο πεδίο γίνεται η ομαδοποίηση και, στη φράση SELECT εκτός από το ΦΥΛΟ, προβάλουμε ένα νέο υπολογιζόμενο πεδίο (δείτε ενότητα 4.2) με όνομα ΠΟΣΟΙ_ΕΙΝΑΙ που έχει τιμή το πλήθος (COUNT) των θαμώνων. Το επόμενο ερώτημα βρίσκει τις ηλικίες του νεότερου και του γηραιότερου θαμώνα κατά φύλο και υπολογίζει και το μέσο όρο της ηλικίας. SELECT ΦΥΛΟ, igaviotis@gmail.com 25-Νοε-16 Σελ. 11

12 Min(ΗΛΙΚΙΑ) AS ΝΕΟΤΕΡΟΣ, Max(ΗΛΙΚΙΑ) AS ΓΗΡΑΙΟΤΕΡΟΣ, Avg(ΗΛΙΚΙΑ) AS ΜΕΣΗ_ΗΛΙΚΙΑ FROM ΘΑΜΩΝΕΣ GROUP BY ΦΥΛΟ Δείτε στην Εικόνα 10 διάφορες συναρτήσεις που μπορούν να χρησιμοποιηθούν σε ερωτήματα ομαδοποίησης. Ας δούμε πόσα μπαράκια άνοιξαν ανά έτος: SELECT Year(ΗΜ_ΑΝΟΙΓΜ) AS ΕΤΟΣ, Count(ΟΝΟ_ΜΠΑΡ) AS ΠΟΣΑ_ΜΠΑΡ FROM ΜΠΑΡΑΚΙΑ GROUP BY Year(ΗΜ_ΑΝΟΙΓΜ) Και ένα πιο σύνθετο ερώτημα ομαδοποίησης που περιλαμβάνει και σύνδεση πινάκων: SELECT ΦΥΛΟ, ΘΑΜΩΝΑΣ, Count(ΠΟΤΟ) AS ΠΟΣΑ_ΠΟΤΑ FROM ΘΑΜΩΝΕΣ INNER JOIN ΠΙΝΕΙ ON ΟΝΟ_ΘΑΜ = ΘΑΜΩΝΑΣ GROUP BY ΦΥΛΟ, ΘΑΜΩΝΑΣ Αυτό το ερώτημα εμφανίζει ανά φύλο και άτομο πόσα ποτά πίνει. Count Πλήθος Sum Min Max Avg Άθροισμα Ελάχιστο Μέγιστο Μέσος όρος First Πρώτη εγγραφή Last Τελευταία εγγραφή Εικόνα 10 Συναρτήσεις ομαδοποίησης Τέλος μια διπλή σύνδεση με τρεις πίνακες που βρίσκει για κάθε θαμώνα, από τα ποτά που πίνει, ποιο έχει το περισσότερο αλκοόλ. SELECT ΦΥΛΟ, ΘΑΜΩΝΑΣ, Max(ΑΛΚΟΟΛ) AS ΠΙΟ_ΒΑΡΥ FROM ΠΟΤΑ INNER JOIN (ΘΑΜΩΝΕΣ INNER JOIN ΠΙΝΕΙ ON ΟΝΟ_ΘΑΜ = ΘΑΜΩΝΑΣ) ON ΟΝΟ_ΠΟΤ = ΠΟΤΟ GROUP BY ΦΥΛΟ, ΘΑΜΩΝΑΣ 4.6 Παραλλαγές σύνδεσης: αταίριαστα και σταυρώματα Μπορεί να αναρωτηθήκατε ήδη γιατί να υπάρχει αυτό το INNER στη φράση σύνδεσης JOIN των πινάκων. Είπαμε ότι στο αποτέλεσμα μιας INNER JOIN βρίσκουμε μόνο τις σχετικές εγγραφές από τους δυο πίνακες με βάση το πεδίο σύνδεσης. Έτσι το ερώτημα SELECT ΟΝΟ_ΘΑΜ, ΗΛΙΚΙΑ, ΜΠΑΡ, ΗΜΕΡΑ FROM ΘΑΜΩΝΕΣ INNER JOIN ΣΥΧΝΑΖΕΙ ON ΘΑΜΩΝΕΣ.ΟΝΟ_ΘΑΜ = ΣΥΧΝΑΖΕΙ.ΘΑΜΩΝΑΣ με βάση τα δεδομένα εισόδου θα δώσει τα αποτελέσματα που φαίνονται στην Εικόνα 11. Εικόνα 11 Οι πίνακες και το αποτέλεσμα του ερωτήματος σύνδεσης igaviotis@gmail.com 25-Νοε-16 Σελ. 12

13 Μερικές φορές (σπάνια, είναι αλήθεια) χρειάζεται να συνδέσουμε πίνακες και στο αποτέλεσμα να εμφανίζονται όλες οι εγγραφές του ενός πίνακα, ακόμα κι αν δεν υπάρχουν σχετικές εγγραφές στον δεύτερο πίνακα. Για παράδειγμα, το SELECT ΟΝΟ_ΘΑΜ, ΗΛΙΚΙΑ, ΜΠΑΡ, ΗΜΕΡΑ FROM ΘΑΜΩΝΕΣ LEFT JOIN ΣΥΧΝΑΖΕΙ ON ΘΑΜΩΝΕΣ.ΟΝΟ_ΘΑΜ = ΣΥΧΝΑΖΕΙ.ΘΑΜΩΝΑΣ θα δώσει στο αποτέλεσμα και τον Πάνο που δεν συχνάζει σε κανένα μπαράκι (δείτε την τελευταία εγγραφή στην Εικόνα 12). Σημειώστε ότι δεν χρησιμοποιείται INNER JOIN, αλλά LEFT JOIN για να δώσει όλες τις εγγραφές του πίνακα που είναι στα αριστερά της JOIN. Στο αποτέλεσμα του ερωτήματος παρατηρήστε ότι για τον Πάνο τα πεδία ΜΠΑΡ και ΗΜΕΡΑ είναι κενά (ακριβέστερα, έχουν τιμή NULL), αφού δεν έχει αντίστοιχες εγγραφές στον πίνακα ΣΥ- ΧΝΑΖΕΙ. Αυτό μπορούμε να το χρησιμοποιήσουμε για να βρούμε εγγραφές ενός πίνακα που δεν έχει σχετικές εγγραφές στο δεύτερο πίνακα. Για παράδειγμα, οι θαμώνες που δεν συχνάζουν σε κανένα μπαρ είναι SELECT ΟΝΟ_ΘΑΜ FROM ΘΑΜΩΝΕΣ LEFT JOIN ΣΥΧΝΑΖΕΙ ON ΘΑΜΩΝΕΣ.ΟΝΟ_ΘΑΜ = ΣΥΧΝΑΖΕΙ.ΘΑΜΩΝΑΣ WHERE ΜΠΑΡ Is Null Στο αποτέλεσμα αυτού του ερωτήματος θα εμφανίζεται μόνο ο Πάνος. Αυτό είναι ένα παράδειγμα για την Εικόνα 12 Εξωτερική σύνδεση εύρεση «αταίριαστων» εγγραφών. Τα LEFT JOIN και RIGHT JOIN λέγονται εξωτερικές συνδέσεις σε αντιδιαστολή με το συνηθισμένο INNER JOIN που είδαμε πρωτύτερα. Ας πούμε τώρα ότι θέλουμε να βρούμε όλα τα πιθανά ζεύγη θαμώνων, αφού το φυσιολογικό είναι κάποιος να πηγαίνει στο μπαρ με παρέα. Αυτό γράφεται SELECT ΑΤΟΜΟ_1.ΟΝΟ_ΘΑΜ, ΑΤΟΜΟ_2.ΟΝΟ_ΘΑΜ FROM ΘΑΜΩΝΕΣ AS ΑΤΟΜΟ_1, ΘΑΜΩΝΕΣ AS ΑΤΟΜΟ_2 Για την ιστορία, αυτό είναι ένα ερώτημα σταυρώματος (cross query). Σε αυτό το ερώτημα χρησιμοποιώ τον ίδιο πίνακα δυο φορές και για να ξεχωρίζω σε ποιον αναφέρομαι, τους ονοματίζω με τη φράση AS. Καθώς οι θαμώνες είναι 8, όλοι οι δυνατοί συνδυασμοί τους είναι 8Χ8, άρα το αποτέλεσμα θα έχει 16 ζευγάρια (Εικόνα 13). Βέβαια, αν κάποιος έχει καταφέρει να φτάσει μέχρι εδώ χωρίς να θολώσει το μυαλό του, θα έχει αντιρρήσεις με την ιδέα ότι οι θαμώνες βγαίνουν να πιουν παρέα με τον εαυτό τους. Προς χάρη του οξυδερκούς αναγνώστη, βελτιώνουμε το ερώτημα ως SELECT ATOMO_1.ΟΝΟ_ΘΑΜ, ΑΤΟΜΟ_2.ΟΝΟ_ΘΑΜ FROM ΘΑΜΩΝΕΣ AS ATOMO_1, ΘΑΜΩΝΕΣ AS ΑΤΟΜΟ_2 WHERE ATOMO_1.ΟΝΟ_ΘΑΜ <> ΑΤΟΜΟ_2.ΟΝΟ_ΘΑΜ που κόβει τα ζευγάρια κάθε ανθρώπου με τον εαυτό του. Και επειδή είπαμε για ζευγάρια, ας το περιορίσουμε στα ετερόφυλα ζευγάρια ως εξής: SELECT ΚΑΒΑΛΙΕΡΟΣ.ΟΝΟ_ΘΑΜ, ΝΤΑΜΑ.ΟΝΟ_ΘΑΜ FROM ΘΑΜΩΝΕΣ AS ΚΑΒΑΛΙΕΡΟΣ, ΘΑΜΩΝΕΣ AS ΝΤΑΜΑ WHERE ΚΑΒΑΛΙΕΡΟΣ.ΟΝΟ_ΘΑΜ <> ΝΤΑΜΑ.ΟΝΟ_ΘΑΜ AND ΚΑΒΑΛΙΕΡΟΣ.ΦΥΛΟ='Α' AND ΝΤΑΜΑ.ΦΥΛΟ='Γ' Για εξάσκηση, ραφινάρετε το ερώτημα, έτσι ώστε να βγάζει μόνο τα ζευγάρια που η ντάμα είναι νεότερη του καβαλιέρου. Σωστός, ε; Μετά επεκτείνετε το ερώτημα ώστε για αυτά τα ζευγάρια να βρείτε αν συχνάζουν στο ίδιο μπαρ, οπότε υπάρχει πιθανότητα να συναντηθούν. Έπειτα ελέγξτε ότι στα μπαρ αυτά συχνάζουν την ίδια ημέρα της εβδομάδας Τέλος, μετρήστε ποιες είναι οι καλύτερες ημέρες της εβδομάδας που πηγαίνοντας κάποιος σε μπαρ έχει περισσότερες πιθανότητες να βρει ταίρι. Αν απαντήσετε όλα αυτά τα ερωτήματα, σας αξίζει να πάτε σε ένα μπαρ και να τα πιείτε. Εικόνα 13 Ερώτημα σταυρώματος igaviotis@gmail.com 25-Νοε-16 Σελ. 13

14 4.7 Διπλότυπες εγγραφές Ένας πίνακας που δεν έχει πρωτεύον κλειδί επιτρέπεται να δεχθεί εγγραφές που έχουν τις ίδιες τιμές σε όλα τα πεδία τους. Αυτές οι εγγραφές ονομάζονται διπλότυπα, παρότι δεν είναι απαραίτητο να είναι διπλές μπορεί να είναι τριπλές ή εν γένει πολλαπλές. Για παράδειγμα, ας φτιάξουμε έναν πίνακα που αποθηκεύει ποιος θαμώνας πήγε σε ποιο μπαρ ποια ημερομηνία. Σε αυτόν τον πίνακα δεν έχουμε βάλει κλειδί, γι αυτό επιτρέπεται να εισάγουμε διπλότυπες εγγραφές, όπως φαίνεται στην Εικόνα 14, πχ στις πρώτες δύο εγγραφές. Με την κανονική SELECT * FROM ΠΗΓΕ Θα εμφανιστούν όλες οι εγγραφές του πίνακα. Αν θέλουμε να "κόψουμε τις διπλότυπες τιμές, γράφουμε SELECT DISTINCT * FROM ΠΗΓΕ και εμφανίζονται έξι εγγραφές που δεν περιέχουν τα διπλότυπα παρά μια φορά το καθένα. Μπορούμε να περικόψουμε τα διπλότυπα επιλέγοντας δύο από τα πεδία του πίνακα με την SELECT DISTINCT ΠΕΛΑΤΗΣ, ΜΠΑΡ FROM ΠΗΓΕ Το ίδιο αποτέλεσμα μπορούμε να επιτύχουμε με τη γνωστή φράση GROUP BY ως εξής: SELECT ΠΕΛΑΤΗΣ, ΜΠΑΡ FROM ΠΗΓΕ GROUP BY ΠΕΛΑΤΗΣ, ΜΠΑΡ Μερικές φορές τα διπλότυπα είναι ανεπιθύμητα σε έναν πίνακα. Μπορεί να προήλθαν, πχ γιατί δυο χρήστες εισήγαγαν την ίδια πληροφορία χωρίς ο ένας να ξέρει ότι η πληροφορία αυτή ήδη υπήρχε στη ΒΔ. Ένας έξυπνος τρόπος να βρούμε αν ένας πίνακας περιέχει διπλότυπα και ποια είναι αυτά, είναι με το ερώτημα SELECT First(ΠΕΛΑΤΗΣ), First(ΜΠΑΡ, First(ΗΜΝΙΑ), Count(ΠΕΛΑΤΗΣ) AS ΠλήθοςΔιπλοτύπων FROM ΠΗΓΕ GROUP BY ΠΕΛΑΤΗΣ, ΜΠΑΡ, ΗΜΝΙΑ HAVING Count(ΠΕΛΑΤΗΣ)>1 Εδώ το κόλπο είναι το υπολογιζόμενο πεδίο Εικόνα 14 Αρχικός πίνακας, χωρίς διπλότυπα σε όλα τα πεδία, στα δύο πεδία Εικόνα 15 Ερώτημα διπλοτύπων Count(ΠΕΛΑΤΗΣ) που μετρά το πλήθος των εγγραφών της ομαδοποίησης πριν ομαδοποιηθούν (δείτε Εικόνα 15). Η συνάρτηση ομαδοποίησης First χρησιμοποιείται αυθαίρετα θα μπορούσαμε να έχουμε χρησιμοποιήσει τη Last, ή τη Min ή τη Max και όλες θα έδιναν το ίδιο αποτέλεσμα, αφού πρόκειται για τις διπλότυπες τιμές. Έπειτα χρησιμοποιείται η φράση HAVING που λειτουργεί με κριτήρια επί συναρτήσεων ομαδοποίησης (ανατρέξτε στην Εικόνα 10) για να προβάλει μόνο τα διπλότυπα και τον πληθάριθμό τους. Αν θέλουμε να αποκλείσουμε τη δυνατότητα ύπαρξης διπλότυπων μέσα στον πίνακα εκ των προτέρων, μπορούμε να εισάγουμε ένα περιορισμό μοναδικότητας, αλλά αυτό θα το δούμε αργότερα στην ενότητα 6.2. igaviotis@gmail.com 25-Νοε-16 Σελ. 14

15 5. Ορισμός σχήματος ΒΔ με SQL Η εντολή SELECT της SQL είναι αναμφισβήτητα η πιο συχνά χρησιμοποιούμενη εντολή για έναν προγραμματιστή, καθώς επιτρέπει τον συνδυασμό των δεδομένων των πινάκων και τον υπολογισμό χρήσιμης πληροφορίας. Ας πάρουμε όμως την πορεία μιας ΒΔ από την αρχή. Στο ξεκίνημα πρέπει να δημιουργήσουμε μια νέα, κενή ΒΔ και μετά να ορίσουμε τους πίνακες και τις σχέσεις τους, αυτό που λέμε σχήμα της ΒΔ (database schema). Αυτό μπορεί να γίνει με τον εύκολο τρόπο και με τον επαγγελματικό τρόπο. Ο εύκολος τρόπος είναι να χρησιμοποιήσει ο διαχειριστής της ΒΔ το περιβάλλον γραφικής διεπαφής, όπως αυτό που συναντάει κανείς στην MS Access, ή το SQL Server Management Studio, ή τον Enterprise Manager/SQL Developer της Oracle ή το MySQL Workbench. Εκεί εύκολα, γρήγορα και χωρίς να γράψει γραμμή κώδικα μπορεί να ορίσει πίνακες, πεδία, κλειδιά και περιορισμούς ακεραιότητας. Ο «επαγγελματικός» (ή παλιομοδίτικος) τρόπος είναι γράφοντας ειδικές εντολές SQL που ανήκουν σε ένα υποσύνολο της SQL που ονομάζεται Γλώσσα Ορισμού Δεδομένων (Data Definition Language, DDL) 5. Ας δούμε λοιπόν για λόγους πληρότητας της γνώσης, κάλυψης της διδακτέας ύλης και ιστορικής αναδρομής πώς συντάσσεται η κυριότερη εντολή DDL, η CREATE 6. Το παράδειγμα που θα χρησιμοποιήσουμε αφορά τη ΒΔ με άτομα που κατοικούν σε κάποια πόλη. Αναγνωρίζουμε ότι πρόκειται για μια σχέση ένα-προς-πολλά, αφού σε μια πόλη ζουν πολλά άτομα και το κάθε άτομο κατοικεί σε μια μόνο πόλη. Άτομο Κατοικεί Πόλη Αρχικά κατασκευάζουμε μια νέα, κενή ΒΔ με την εντολή CREATE DATABASE KATOIKOI; Οι επόμενες εντολές δημιουργούν πίνακες σε μια υπάρχουσα ΒΔ. Για να επιλέξουμε τη ΒΔ μέσα στην οποία θα λειτουργούμε, η εντολή είναι USE KATOIKOI; Έπειτα δημιουργούμε τον πίνακα των πόλεων, ορίζοντας τα πεδία του και τον τύπο δεδομένων για καθένα από αυτά. CREATE TABLE POLH ( TAX_KOD DECIMAL(5,0) PRIMARY KEY, ONO_POL VARCHAR(40) NOT NULL, PERIFEREIA VARCHAR(20) ); Αναγνωρίζετε ότι για κάθε πεδίο, εκτός από το όνομά του, δηλώνουμε τον τύπο δεδομένων που αποθηκεύει και το μέγεθος του. Οι κυριότεροι τύποι δεδομένων της τυποποιημένης SQL φαίνονται στον διπλανό πίνακα περισσότερα για τους τύπους δεδομένων της SQL στην ενότητα 5.1. Επίσης, με την εντολή δημιουργίας του πίνακα καθορίσαμε ότι: Το πεδίο TAX_KOD είναι ένας πενταψήφιος αριθμός, χωρίς δεκαδικά ψηφία. Το πεδίο TAX_KOD είναι το κλειδί του πίνακα (φράση PRIMARY KEY), συνεπώς δυο πόλεις δεν επιτρέπεται να έχουν ίδια τιμή στο TAX_KOD. Το πεδίο ONO_POL πρέπει να συμπληρώνεται υποχρεωτικά δεν μπορεί να μείνει κενό (φράση NOT NULL) VARCHAR (n) DECIMAL(m, d) Το πεδίο PERIFEREIA μπορεί να πάρει ως τιμές συμβολοσειρές μήκους μέχρι 20 χαρακτήρων, αλλά επιτρέπεται να μείνει κενό (τιμή NULL). Αν αλλάξουμε γνώμη για κάτι και πρέπει να τροποποιήσουμε τη σχεδίαση του πίνακα, το ευκολότερο είναι να τον διαγράψουμε με την εντολή DROP TABLE POLH; και να τον ξαναδημιουργήσουμε από την αρχή. DATE TIME DATETIME Συμβολοσειρά μήκους μέχρι n χαρακτήρων Αριθμός με m ψηφία, εκ των οποίων d δεκαδικά Ημερομηνία Ώρα Ημερομηνία και ώρα Εικόνα 16 Οι βασικοί τύποι δεδομένων της SQL 5 Παρεμπιπτόντως, η SELECT και άλλες εντολές που λειτουργούν στα δεδομένα της ΒΔ και δεν τροποποιούν το σχήμα της, αποτελούν τη Γλώσσα Χειρισμού Δεδομένων (Data Manipulation Language, DML). 6 Τα παραδείγματα έχουν δοκιμαστεί στα ΣΔΒΔ SQL Server, το οποίο θα χρησιμοποιήσουμε και αργότερα όταν θα ασχοληθούμε με ασφάλεια (χρήστες, δικαιώματα, κ.λπ.). Επίσης έχουν δοκιμαστεί με μικρές τροποποιήσεις στην Oracle. igaviotis@gmail.com 25-Νοε-16 Σελ. 15

16 Ακολουθεί ο πίνακας των ατόμων CREATE TABLE ATOMO ( ADT VARCHAR(10) PRIMARY KEY, ONO_ATOM VARCHAR(40) NOT NULL, HM_GEN DATE, YPSOS DECIMAL(5,2), POLH_POU_ZEI DECIMAL(5,0) REFERENCES POLH(TAX_KOD) ); Τι νέο μαθαίνουμε από αυτό το παράδειγμα: Το πεδίο YPSOS μπορεί να πάρει 2 δεκαδικά ψηφία και άλλα 3 ακέραια ψηφία, π.χ. την τιμή Η POLH_POU_ZEI είναι ξένο κλειδί που συνδέεται με το πεδίο TAX_KOD του πίνακα POLH. Η μορφή της εντολής δημιουργίας νέου πίνακα είναι: CREATE TABLE ( πεδίο1 τύποςδεδομένων1, πεδίο2 τύποςδεδομένων2,... ); για όσα πεδία χρειάζονται. Μετά τον καθορισμό του τύπου δεδομένων, μπορούμε να βάλουμε τις φράσεις PRIMARY KEY για το πρωτεύον κλειδί, REFERENCES για σύνδεση με ξένο κλειδί και NOT NULL για απαγόρευση κενών τιμών. Ας πούμε ότι για τα άτομα μας ενδιαφέρει εκτός από τον Αριθμό Δελτίου Ταυτότητας (πεδίο ADT) και ο αριθμός μητρώου κοινωνικής ασφάλισης που είναι και αυτός μοναδικός για τον καθένα μας. Για να προσθέσουμε το νέο αυτό πεδίο στον πίνακα, γράφουμε ALTER TABLE ATOMO ADD AMKA CHAR(11) NOT NULL UNIQUE; Ανακεφαλαιώνοντας, οι εντολές CREATE TABLE και DROP TABLE είναι οι δυο σημαντικότερες εντολές της Γλώσσας Ορισμού Δεδομένων που λειτουργούν πάνω σε πίνακες. Άλλες εντολές της DDL που δεν θα σας χρειαστούν, παρά μόνον αν εξαναγκαστείτε να διαχειρίζεστε τη ΒΔ από το περιβάλλον γραμμής εντολών (command line) χωρίς το γραφικό περιβάλλον του ΣΔΒΔ είναι η RENAME που αλλάζει το όνομα ενός πίνακα και η ALTER TABLE που τροποποιεί τη δομή του προσθέτοντας / αλλάζοντας / διαγράφοντας πεδία. 5.1 Τύποι δεδομένων της SQL Εικόνα 17 Το σχήμα της ΒΔ KATOIKOI στον SQL Server Κατά τη σχεδίαση των πινάκων της ΒΔ, αφού προσδιορίσουμε τα πεδία που συμμετέχουν στον κάθε πίνακα πρέπει να ορίσουμε τι τύπου δεδομένα θα αποθηκεύονται σε κάθε πεδίο. Ο τύπος δεδομένων καθορίζει το πεδίο τιμών, δηλαδή τη γκάμα των πιθανών τιμών που μπορεί να λάβει, και τις λειτουργίες (πχ αριθμητικές, σύγκρισης & ταξινόμησης) που μπορούν να επιτελεστούν στις τιμές του τύπου δεδομένων. Ήδη έχουμε χρησιμοποιήσει τους βασικούς τύπους δεδομένων (δείτε στην Εικόνα 16), τώρα θα πούμε λίγα πράγματα παραπάνω. Μπορούμε να εντάξουμε τους τύπους δεδομένων που αποθηκεύονται σε ΒΔ σε τέσσερεις ομάδες: Συμβολοσειρά Είναι ο πιο συνηθισμένος τύπος δεδομένων που δέχεται ως τιμές ακολουθίες χαρακτήρων μέχρι ενός ορισμένου μήκους. Οποιοσδήποτε χαρακτήρας (γράμμα, αριθμητικό ψηφίο, ειδικός χαρακτήρας) μπορεί να περιέχεται σε οποιαδήποτε θέση. Αριθμός Υπάρχουν διάφοροι τύποι αριθμών, τόσο ως προς την εμφάνισή τους, πχ που έχουν ή δεκαδικά ψηφία ή είναι ακέραιοι, όσο και ως προς την εσωτερική τους αναπαράσταση, πχ είναι κατάλληλοι για αριθμητικές πράξεις, ή συγκρίσεις, ή νομισματικές τιμές. Ημερομηνία/Ώρα Και εδώ υπάρχουν διαφοροποιήσεις ως προς την ακρίβεια. Για παράδειγμα, για το πεδίο ΓΕΝΕΘΛΙΑ αρκεί μια ημερομηνία , για το ΠΡΟΣΕΛΕΥΣΗ μια τιμή :04:56, ενώ για τον τερματισμό ενός αγώνα F1 04:39:45.12 Δυαδικά (binary) δεδομένα Πέρα από τα πεδία Ναι/Όχι, μπορεί να έχουμε ακολουθίες δυαδικών ψηφίων 7. Δυστυχώς, υπάρχουν μεγάλες διαφορές στους τύπους δεδομένων ανάμεσα στα διάφορα ΣΔΒΔ, οπότε παρακάτω θα παρουσιάσουμε την εκδοχή της τυποποιημένης ANSI SQL που τα καταραμένα ΣΔΒΔ δεν υποστηρίζουν πλήρως και ακόμα χειρότερα υπάρχουν περιπτώσεις που υποστηρίζουν το συντακτικό και τις δεσμευμένες λέξεις, αλλά η υλοποίησή τους διαφέρει, πχ ανάμεσα σε Oracle και SQL Server. 7 Αρκετά σύγχρονα ΣΔΒΔ έχουν ειδικούς τύπους δεδομένων για δυαδικά δεδομένα μεγάλου μεγέθους, όπως είναι οι εικόνες, βίντεο και άλλα δυαδικά αρχεία που επιθυμούμε να αποθηκεύονται μέσα στη ΒΔ και όχι στο σύστημα αρχείων. Για τέτοια δεδομένα έχει επικρατήσει η ονομασία BLOB (Binary Large OBjects). igaviotis@gmail.com 25-Νοε-16 Σελ. 16

17 Για τις συμβολοσειρές ξεκινάμε με τον τύπο δεδομένων CHAR(n) που δεσμεύει χώρο για n χαρακτήρες στο πεδίο, ακόμα κι αν αποθηκεύσουμε λιγότερους (ωστόσο, απαγορεύεται να αποθηκεύσουμε περισσότερους από n). Το υπόλοιπο παραγεμίζεται με χαρακτήρες κενού (space). Οι χαρακτήρες αναπαριστώνται κατά τον κώδικα ASCII, άρα καθένας καταλαμβάνει χώρο 1 byte. Αν φιλοδοξείτε η ΒΔ που κατασκευάζετε να λειτουργεί σε πολλές χώρες και χρειάζεται να αποθηκεύει συμβολοσειρές σε πολλά αλφάβητα του κόσμου, η λύση ονομάζεται NCHAR(n), που αποθηκεύει πάλι n χαρακτήρες αλλά κατά το πρότυπο Unicode αυτή τη φορά, άρα ο κάθε χαρακτήρας θα σας κοστίσει 2 byte χώρου. Τώρα αν σας έπιασαν (αδικαιολόγητες στις μέρες μας) τσιγκουνιές για χώρο, υπάρχει η εκδοχή NVARCHAR(n) που αποθηκεύει πάλι κατά Unicode, αλλά δεν δεσμεύει 2n bytes για όλες τις συμβολοσειρές. Αντίθετα, αποθηκεύει το πεδίο ως συμβολοσειρά μεταβλητού μήκους και χρειάζεται χώρο ανάλογο με το μήκος της εκάστοτε τιμής για κάθε εγγραφή. Βέβαια, ως γνωστόν, η φτώχεια τρώει τον παρά, και έτσι ίσως η αναπαράσταση μεταβλητού μήκους να είναι πιο αργή από την σταθερού μήκους. Πάντως, η συνήθης πρακτική είναι να δηλώνετε όλα τα πεδία τύπου συμβολοσειράς ως NVARCHAR(n) 8. Οι αριθμητικοί τύποι δεδομένων είναι μια άλλη πονεμένη ιστορία στην SQL. Οι ακέραιοι δηλώνονται ως INTEGER και βέβαια δεν έχουν δεκαδικά ψηφία, ενώ μπορούν να πάρουν αρνητικές και θετικές τιμές. Μη ρωτήσετε όμως ποια είναι η μεγαλύτερη τιμή που μπορούν να έχουν 9. Οι πραγματικοί δηλώνονται ως REAL είτε ως DOUBLE PRECISION (διπλής ακρίβειας) και για τις τιμές τους ισχύει το ίδιο μπάχαλο που είδαμε στους ακέραιους. Η πιο ασφαλής επιλογή για αριθμούς είναι η δήλωση DECIMAL(m, d) ή NUMERIC(m, d) που δέχεται αριθμούς με m το πολύ ψηφία, εκ των οποίων τα d είναι δεκαδικά. Για παράδειγμα, το πεδίο για το μισθό ενός εργαζόμενου μπορεί να δηλωθεί DECIMAL(6, 2) που μπορεί να πάρει τιμή ως Έτσι καλύπτουμε μέχρι και τον μισθό του πρωθυπουργού μας που είναι Πάντως, όπως πάνε τα πράγματα, θα μπορούμε να δηλώνουμε μισθούς με DECIMAL(5, 2) και ευχαριστημένοι να 'μαστε... Για ημερομηνίες υπάρχει η δήλωση DATE και συνήθως οι τιμές γράφονται σε μορφή ΕΕΕΕ-ΜΜ-ΗΗ, για ώρες υπάρχει η δήλωση TIME και οι τιμές συνήθως γράφονται ΩΩ:ΛΛ:ΔΔ. Η δήλωση DATETIME περιλαμβάνει ημερομηνία και ώρα με ακρίβεια τουλάχιστον δευτερολέπτου, αλλά συνήθως τα δευτερόλεπτα δέχονται και δεκαδικά ψηφία. Για δυαδικά δεδομένα υπάρχει η δήλωση BIT(n) που ορίζει μια ακολουθία n δυαδικών ψηφίων. Αν n=1, τότε μπορούμε να αποθηκεύσουμε τις τιμές 0 και 1. Μια ασφαλής συμβουλή σε ότι αφορά τους τύπους δεδομένων είναι να γνωρίζετε αυτούς που βρίσκονται στην Εικόνα 16 και, αν ποτέ χρειαστείτε κάτι πιο συγκεκριμένο, να ανατρέξετε στην τεκμηρίωση του συγκεκριμένου ΣΔΒΔ που χρησιμοποιείτε. 5.2 Οριζόμενοι τύποι δεδομένων Εδώ θα κάνουμε μια σύντομη αναφορά στη δυνατότητα που δίνει η SQL στο διαχειριστή της ΒΔ να ορίζει δικούς του τύπους δεδομένων. Η εντολή λέγεται CREATE TYPE 10 και να δυο παραδείγματα: CREATE TYPE TYPOS_ONOMA FROM NVARCHAR(20) NOT NULL; --για ονόματα ανθρώπων CREATE TYPE TYPOS_TK FROM DECIMAL(5,0); -για ελληνικούς ταχυδρομικούς κώδικες CREATE TABLE PERSON ( ONOMA TYPOS_ONOMA, EPONYMO TYPOS_ONOMA, ODOS NVARCHAR(40), TK TYPOS_TK ); Εδώ ορίσαμε δυο δικούς μας τύπους δεδομένων και στην τρίτη εντολή φτιάξαμε ένα πίνακα που τα πεδία του είναι ορισμένα με τους νέους τύπους δεδομένων μας. Έτσι έχουμε κάποιου είδους επαναχρησιμοποίηση: αν ξαναφτιάξουμε τη ΒΔ αλλάζοντας το μήκος του TYPOS_ONOMA από 20 σε 30, τότε όπου έχουμε δηλώσει τέτοια πεδία, θα πάρουν το νέο μήκος. 6. Περιορισμοί ακεραιότητας Είναι καλή πρακτική που σπανίως ακολουθείται στην πραγματικότητα όταν υλοποιούμε το σχήμα της ΒΔ, δημιουργώντας τους πίνακες και ορίζοντας τα πεδία τους, να προσπαθούμε να είμαστε αυστηροί με τις προδιαγραφές που θα πρέπει να τηρούν τα δεδομένα που θα τοποθετηθούν μέσα στους πίνακες. Αυτές οι προδιαγραφές, ή περιορισμοί ακεραιότητας προκύπτουν από τη φύση των δεδομένων και τη χρήση τους στη ΒΔ. 6.1 Περιορισμοί εγκυρότητας τιμών Οι πιο απλοί κανόνες περιορίζουν το εύρος των τιμών του πεδίου. Για παράδειγμα, το πεδίο μισθός είναι ένας αριθμός με 6 ψηφία από τα οποία τα δύο είναι δεκαδικά, αλλά, όπως ξέρουμε, ο μισθός δεν μπορεί να είναι αρνητικός. Επίσης, το ύψος εκφρασμένο σε εκατοστά, είναι ένας αριθμός με τιμές από 100 ως 250. Έτσι μπορούμε να δημιουργήσουμε τον πίνακα με την CREATE TABLE ERGAZOMENOS ( ONOMA NVARCHAR(40) NOT NULL, MISTHOS DECIMAL (6,2) ) NOT NULL CHECK (MISTHOS > 0), 8 Παρεμπιπτόντως το μήκος n δεν μπορεί να είναι πολύ μεγάλο. Στην Access φτάνει το 255 και στην Oracle to Αν θέλετε να αποθηκεύσετε το κείμενο ενός βιβλίου ως πεδίο συμβολοσειράς, δείτε τους τύπους δυαδικών δεδομένων. 9 Στην Access (16 bit), στον SQL Server 2 δις (32 bit), στην Oracle 38 δεκαδικά ψηφία! 10 Σε μερικά ΣΔΒΔ, όπως στην PostgreSQL, ονομάζεται CREATE DOMAIN. igaviotis@gmail.com 25-Νοε-16 Σελ. 17

18 YPSOS INTEGER CHECK (YPSOS BETWEEN 100 AND 260), --ΣΕ ΕΚΑΤΟΣΤΑ HM_GEN DATE CHECK (HM_GEN < ' '), FYLO NCHAR(1) CHECK (FYLO = 'Α' OR FYLO = 'Γ') ); Άρα για κάθε πεδίο του πίνακα μετά το όνομά του και τον τύπο δεδομένων του μπορούμε να έχουμε τη φράση CHECK που επιβάλει έναν κανόνα που αφορά τις τιμές του πεδίου 11. Με ευθύνη του ΣΔΒΔ, σε καμιά περίπτωση δεν μπορεί να προκύψει εγγραφή στον πίνακα που να παραβιάζει κάποιον από τους κανόνες ακεραιότητας, είτε από νεοεισερχόμενη εγγραφή, είτε από τροποποίηση υφιστάμενης εγγραφής. Ο κανόνας είναι εκεί και τηρείται πάντα και από όλους. Έτσι αν προσπαθήσω INSERT INTO ERGAZOMENOS VALUES ('ΝΙΚΟΣ ΑΝΔΡΕΟΥ', , 261, ' ', 'Α'); θα χτυπήσει σφάλμα με διαγνωστικό μήνυμα: The INSERT statement conflicted with the CHECK constraint "CK ERGAZOMEN YPSOS 31EC6D26". The conflict occurred in database "TEST", table "dbo.ergazomenos", column 'YPSOS'. Ίσως προσέξατε στον ορισμό του πεδίου ONOMA τη φράση NOT NULL. Αυτός ο κανόνας απαγορεύει να εισαχθεί μια εγγραφή στον πίνακα από την οποία να λείπει το όνομα του εργαζομένου. INSERT INTO ERGAZOMENOS (ONOMA, FYLO) VALUES ('ΑΝΝΑ ΠΑΠΠΑ', 'Γ'); Cannot insert the value NULL into column 'MISTHOS', table 'TEST.dbo.ERGAZOMENOS'; column does not allow nulls. INSERT fails. Αντίθετα, μπορεί να λείπει πχ. το ύψος του και η ημερομηνία γέννησης, χωρίς πρόβλημα INSERT INTO ERGAZOMENOS (ONOMA, MISTHOS, FYLO) VALUES ('ΑΝΝΑ ΠΑΠΠΑ', , 'Γ'); δίνει πίνακα ONOMA MISTHOS YPSOS HM_GEN ΝΙΚΟΣ ΑΝΔΡΕΟΥ ΑΝΝΑ ΠΑΠΠΑ NULL NULL Γενικά καλό είναι να αποφεύγουμε να επιτρέπουμε τις κενές τιμές. Εννοείται ότι αργότερα στη ζωή της ΒΔ οι κενές τιμές μπορούν να συμπληρωθούν από νόμιμες τιμές, σύμφωνα με τον κανόνα ακεραιότητας του πεδίου. Μερικές φορές θέλουμε να επιβάλουμε κανόνες που εμπλέκουν τιμές πολλών πεδίων του πίνακα. Για παράδειγμα, ας υποθέσουμε ότι το αφεντικό της επιχείρησης απαιτεί το (σεξιστικό) κανόνα να μην προσλαμβάνονται γυναίκες που έχουν γεννηθεί πριν το 1990, ενώ για τους άντρες δεν υπάρχει όριο ηλικίας. Μπορούμε να επιβάλουμε ένα κανόνα τροποποιώντας τον ορισμό του πίνακα με την εντολή ALTER TABLE ERGAZOMENOS ADD CONSTRAINT CK_oxi_grioules CHECK (FYLO = 'Α' OR (FYLO = 'Γ' AND HM_GEN > ' ')); Μέχρι στιγμής έχουμε καλύψει κανόνες ακεραιότητας που αφορούν τις νόμιμες τιμές που μπορούν να λάβουν τα πεδία των εγγραφών του πίνακα για να αντανακλούν τους περιορισμούς που ισχύουν στον πραγματικό κόσμο. Τώρα θα δούμε κανόνες που έχουν σχέση με την πολλαπλότητα των εγγραφών και τη σύνδεση πινάκων μέσω ξένων κλειδιών. 6.2 Περιορισμοί πολλαπλότητας Έχουμε δει ότι στους περισσότερους πίνακες υπάρχει ένα πεδίο που χαρακτηρίζει με μοναδικό τρόπο κάθε εγγραφή και αποτελεί το (πρωτεύον) κλειδί του πίνακα. Αυτό δηλώνεται με τη φράση PRIMARY KEY στο σχετικό πεδίο. CREATE TABLE OXHMA ( PINAKIDA NCHAR(7) NOT NULL PRIMARY KEY, AR_PLAISIOU DECIMAL(20,0), KYBIKA INTEGER ); Όπως γνωρίζουμε, κάθε αυτοκίνητο έχει διαφορετικό αριθμό πλαισίου και θα θέλαμε αυτό να το επιβάλουμε με κανόνα. Αλλιώς, κάποιος μπορεί να κλέβει αυτοκίνητα, να αφαιρεί τις πινακίδες τους, να πηγαίνει στο γραφείο του Υπουργείου Συγκοινωνιών και να βγάζει άλλη πινακίδα, για τον ίδιο αριθμό πλαισίου. Γι αυτό ALTER TABLE OXHMA ADD CONSTRAINT UC_oxi_kleftes UNIQUE (AR_PLAISIOU); Εννοείται ότι τέτοιους περιορισμούς μπορούμε να τους δηλώσουμε από την αρχή στην CREATE TABLE. Ως προς τη λειτουργία τους, δεν υπάρχει διαφορά ανάμεσα σε ένα UNIQUE και σε ένα PRIMARY KEY. Ωστόσο, καταλαβαίνουμε ότι χρησιμοποιούμε το PRIMARY KEY για να συνδέσουμε τον πίνακα με άλλους πίνακες ή να αναζητήσουμε τις εγγραφές 11 Έπεσα από τα σύννεφα όταν έμαθα ότι η MySQL δεν υποστηρίζει την CHECK. Ντροπή! igaviotis@gmail.com 25-Νοε-16 Σελ. 18

19 του 12, ενώ το UNIQUE απλώς αποκλείει διπλότυπα στις τιμές του πεδίου. Τόσο το PRIMARY KEY, όσο και το UNIQUE μπορεί να αποτελούνται από πολλά πεδία, όχι μόνο από ένα. Ας δοκιμάσουμε τώρα τον περιορισμό: INSERT OXHMA VALUES ('ΕΜΑ3205', , 1400); INSERT OXHMA VALUES ('ΕΜΕ5392', , 1400); Μέχρι εδώ όλα καλά, οι δυο εγγραφές μπαίνουν αδιαμαρτύρητα στον πίνακα. Όμως στη συνέχεια: INSERT OXHMA VALUES ('ΕΜΑ3205', , 1400); Violation of PRIMARY KEY constraint 'PK OXHMA 76ECF26C97D0AE71'. Cannot insert duplicate key in object 'dbo.oxhma'. The duplicate key value is (ΕΜΑ3205). Η INSERT δεν ολοκληρώνεται εξαιτίας παραβίασης του πρωτεύοντος κλειδιού. INSERT OXHMA VALUES ('ΕΜΚ5195', , 1600); Violation of UNIQUE KEY constraint 'UQ OXHMA AA8DD158A48768C1'. Cannot insert duplicate key in object 'dbo.oxhma'. The duplicate key value is ( ). Αυτή η INSERT δεν ολοκληρώνεται εξαιτίας παραβίασης του UNIQUE κλειδιού. 6.3 Περιορισμοί αναφοράς Έχουμε μιλήσει αρκετές φορές για πίνακες που συνδέονται με κάποια κοινά πεδία. Σε τέτοιες περιπτώσεις είναι χρήσιμο να επιβάλλεται η σχέση σύνδεσης μεταξύ των πεδίων και των πινάκων τους με τη φράση FOREIGN KEY ως εξής: CREATE TABLE EPISKEVH ( HMNIA DATE NOT NULL, PIN_OXHM NCHAR(7) NOT NULL, PRIMARY KEY (HMNIA, PIN_OXHM), FOREIGN KEY (PIN_OXHM) REFERENCES OXHMA (PINAKIDA) ); Η εντολή ξεκινά δηλώνοντας τα δυο πεδία του πίνακα και μετά δηλώνει ότι συναποτελούν το πρωτεύον κλειδί του πίνακα. Η τελευταία γραμμή ορίζει ότι το πεδίο PIN_OXHM συνδέεται με το πεδίο πινακίδα του πίνακα OXHMA. Και τι πετυχαίνουμε με αυτή τη δήλωση; Καταρχάς επιβάλλεται ότι για κάθε όχημα που πηγαίνει για επισκευή, υπάρχει σχετική εγγραφή στον πίνακα OXHMA. Αυτός ο έλεγχος γίνεται όχι μόνο κατά την εισαγωγή, αλλά και αργότερα, αν πχ προσπαθήσουμε να αλλάξουμε το PIN_OXHM σε κάποια τιμή που δεν υπάρχει στον πίνακα OXHMA. Επιπρόσθετα, ο περιορισμός ξένου κλειδιού δεν θα επιτρέψει τη διαγραφή οχήματος που έχει επισκευαστεί INSERT EPISKEVH VALUES (' ', 'ΕΜΑ3205'); -->OK DELETE FROM OXHMA WHERE PINAKIDA='ΕΜΑ3205'; The DELETE statement conflicted with the REFERENCE constraint "FK EPISKEVH PIN_OX 5CD6CB2B". The conflict occurred in database "TEST", table "dbo.episkevh", column 'PIN_OXHM'. Έτσι αποκλείεται να υπάρξουν «ξεκρέμαστες» εγγραφές. Τέλος μια χρήσιμη επέκταση του περιορισμού αναφοράς που κάνει τη ζωή πιο εύκολη είναι να χρησιμοποιήσουμε τη φράση ON DELETE CASCADE. Αυτή επιβάλλει ότι αν διαγραφεί μια εγγραφή του πίνακα OXHMA που έχει σχετικές εγγραφές στον EPISKEVH, όπως προσπαθήσαμε να κάνουμε πρωτύτερα, η διαγραφή θα ολοκληρωθεί με επιτυχία και θα προκαλέσει την αλυσιδωτή διαγραφή των σχετικών εγγραφών από τις επισκευές, έτσι ώστε να μην μείνουν ξεκρέμαστες. Παρομοίως, η φράση ON UPDATE CASCADE πυροδοτείται κατά την αλλαγή της πινακίδας ενός οχήματος και προκαλεί την αλλαγή της πινακίδας γι αυτό το όχημα στον πίνακα των επισκευών (δείτε Εικόνα 3 για να το θυμηθείτε στην Access). Βολικό, ε; Ανακεφαλαιώνοντας, είδαμε τέσσερα είδη περιορισμών: CHECK που περιορίζει τις τιμές σε αποδεκτό εύρος NOT NULL που απαγορεύει να μένει κενή η τιμή ενός πεδίου PRIMARY KEY / UNIQUE που αποκλείει διπλότυπα FOREIGN KEY... REFERENCES που επιβάλλει συνέπεια στις σχέσεις πινάκων Με τους περιορισμούς ακεραιότητας το σχήμα της ΒΔ μοντελοποιεί με μεγαλύτερη αυστηρότητα το πεδίο που περιγράφει. Επειδή είναι βέβαιο ότι η ΒΔ πάντα θα επιβάλει τους περιορισμούς, είναι σίγουρο ότι θα βρίσκεται πάντα σε νόμιμη κατάσταση και δεν θα γεμίσει «σκουπίδια» μετά από μερικά χρόνια λειτουργίας. Με τίποτα δεν θα εμπιστευόμουνα τους προγραμματιστές των εφαρμογών που τροποποιούν τα περιεχόμενα της ΒΔ για να διατηρήσουν την ακεραιότητά της. 6.4 Παράδειγμα - Ορισμός σχήματος για τη μαγειρική 12 Αρκετές φορές το πρωτεύον κλειδί είναι κατασκευασμένο και η τιμή του δεν έχει κάποια φυσική σημασία, δεν είναι πχ ΑΦΜ ή ΑΔΤ. Τότε είναι βολικό να αφήσουμε το ΣΔΒΔ να δημιουργεί αυτόματα τις τιμές του πεδίου δηλώνοντας KOD_ERGAZ INTEGER IDENTITY(1,1) PRIMARY KEY που δημιουργεί τιμές αύξουσας αρίθμησης ξεκινώντας από το 1 και με βήμα 1. igaviotis@gmail.com 25-Νοε-16 Σελ. 19

20 Για παράδειγμα, ας δούμε τις εντολές DDL για να ορίσουμε το σχήμα της ΒΔ όπως περιγράφεται στην ενότητα 3.1. Θα χρησιμοποιήσουμε MySQL. Αρχικά κατασκευάζουμε τη ΒΔ με την CREATE SCHEMA mageiriki; και μετά για να εκτελούνται όλες οι εντολές σε αυτή τη ΒΔ, χωρίς να αναφέρουμε το όνομά της κάθε φορά USE mageiriki; Ξεκινάμε να φτιάχνουμε τους πίνακες από εκείνους που στέκονται μόνοι τους (δεν περιέχουν ξένα κλειδιά). CREATE TABLE syntagi ( onoma_syntagis NVARCHAR(50) NOT NULL, chef NVARCHAR(40) NOT NULL, xronos_proetoimasias INT UNSIGNED NOT NULL, tropos_mageirematos NVARCHAR(45) NULL, merides INT NOT NULL, einai_ygieini TINYINT(1) NOT NULL, PRIMARY KEY syntagi_pk (onoma_syntagis) ); Και ακολουθούν οι εξαρτώμενοι πίνακες CREATE TABLE yliko ( onoma_ylikou NVARCHAR(30) NOT NULL, posotita DOUBLE UNSIGNED NOT NULL, monada_metrisis NVARCHAR(20) NOT NULL, xreiazetai_gia NVARCHAR(50) NOT NULL, PRIMARY KEY yliko_pk (onoma_ylikou, xreiazetai_gia), CONSTRAINT yliko_syntagis_fk FOREIGN KEY (onoma_ylikou) REFERENCES syntagi (onoma_syntagis) ON DELETE CASCADE ON UPDATE CASCADE ); CREATE TABLE istoriko ( onoma_syntagis NVARCHAR(50) NOT NULL, hmnia_paraskevis DATETIME NOT NULL, kostos_ylikwn DECIMAL(10, 2 ) NULL, apotelesma NVARCHAR(20) NOT NULL, protaseis LONGTEXT NULL, PRIMARY KEY istoriko_pk (hmnia_paraskevis, onoma_syntagis), INDEX istoriko_syntagis_fk (onoma_syntagis), CONSTRAINT istoriko_syntagis_fk FOREIGN KEY (onoma_syntagis) REFERENCES syntagi (onoma_syntagis) ON DELETE CASCADE ON UPDATE CASCADE ); Παρατηρήστε στα ξένα κλειδιά τη φράση με τα CASCADE που εξασφαλίζει την τήρηση του περιορισμού ακεραιότητας σε διαγραφές και ενημερώσεις. Αυτή είναι η ενδεδειγμένη προσέγγιση όταν έχουμε σχέσεις μεταξύ πινάκων μέσω ξένων κλειδιών. Για παράδειγμα, αν διαγραφεί μια συνταγή, αυτομάτως θα διαγραφούν και όλα τα υλικά της, όπως και το ιστορικό των μαγειρεμάτων της. Προφανώς το αντίστροφο ΔΕΝ ισχύει: μπορώ να διαγράψω μερικά ή όλα τα υλικά μιας συνταγής, αλλά η συνταγή θα παραμείνει. Εδώ θα έπρεπε να σταματήσει η κουβέντα, αλλά η SQL υποστηρίζει για τα ON DELETE / ON UPDATE και την (άχρηστη και επικίνδυνη) παραλλαγή SET NULL που επιτρέπει να παραμένουν ξεκρέμαστες εγγραφές στον εξαρτώμενο πίνακα μετά τη διαγραφή / ενημέρωση εγγραφών του πρωτεύοντα πίνακα τοποθετώντας NULL ως τιμή του ξένου κλειδιού. Άβυσσος η ψυχή του ανθρώπου που το πρότεινε αυτό. Παρεμπιπτόντως, η εξ ορισμού συμπεριφορά του FOREIGN KEY REFERENCES όταν δεν βάλεις καθόλου τη φράση ON DELETE / ON UPDATE είναι να απορρίψει την διαγραφή / αλλαγή στον πρωτεύοντα πίνακα, εφόσον υπάρχουν σχετιζόμενες εγγραφές στον δευτερεύοντα αυστηρό αλλά τουλάχιστον ασφαλές. Υπόψιν ότι τα CASCADE λειτουργούν αλυσιδωτά, δηλαδή προκαλούν αλλαγές σε όλους πίνακες σχετίζονται άμεσα ή έμμεσα με τον πίνακα στον οποίο γίνεται η πρώτη αλλαγή. Τώρα που ακόμη δεν έχουμε εισάγει δεδομένα στους πίνακες, αν χρειαστεί να τροποποιήσουμε κάποιον, απλώς εκτελούμε DROP TABLE και τον ξαναφτιάχνουμε στο πι-και-φι με την κατάλληλη CREATE TABLE. Ναι, αλλά αν είχαν μπει δεδομένα μέσα στον πίνακα και δεν μπορούσαμε να τα σβήσουμε (πχ, αν η ΒΔ είναι σε παραγωγική λειτουργία); Ή, ακόμη χειρότερα, αν προσπαθήσετε DROP TABLE syntagi; θα φάτε στα μούτρα το Error Code: Cannot delete or update a parent row: a foreign key constraint fails Και, παρότι το μήνυμα σφάλματος δεν είναι και πολύ επεξηγηματικό, ελπίζω να καταλαβαίνετε γιατί αποτυγχάνει η διαγραφή του πίνακα. Για να ξεφορτωθείτε τον πίνακα syntagi θα έπρεπε να διαγράψετε και όλους τους εξαρτώμενους πίνακες (yliko, istoriko), δεδομένα και σχήμα, και να τους ξαναφτιάξετε και να τους γεμίσετε πιασ το αβγό και κούρευτο. igaviotis@gmail.com 25-Νοε-16 Σελ. 20

21 Η λύση βέβαια σε τέτοια σενάρια είναι η ALTER TABLE που τροποποιεί τον πίνακα χωρίς να τον σβήνει και χωρίς να πειράζει τα δεδομένα που περιέχει, ενώ δεν ενοχλεί και τους εξαρτώμενους πίνακες. Πχ ALTER TABLE yliko MODIFY COLUMN monada_metrisis NVARCHAR(25); 6.5 Διαγράμματα Αν μπήκατε στον κόπο να γράψετε τις CREATE εντολές της προηγούμενης ενότητας και να τις εκτελέσετε για να φτιάξετε τη ΒΔ, τότε θα εκτιμήσετε τη δυνατότητα κατασκευής του Extended Entity Relationship διαγράμματος μέσω της επιλογής Reverse Engineer από το Εικόνα 18 Διάγραμμα EER για τη ΒΔ μενού Database (Εικόνα 18) που μας προσφέρει το MySQL Workbench. Τα διαγράμματα είναι πολύ χρήσιμα, διότι μας δίνουν με εποπτικό τρόπο το σχήμα της ΒΔ με τους πίνακες και τις σχέσεις τους και έτσι μπορούμε ευκολότερα να καταλάβουμε (ή να θυμηθούμε) τη λογική λειτουργίας της ΒΔ. Ειδικά η MySQL έχει εξαιρετικές δυνατότητες μοντελοποίησης με τμηματικά διαγράμματα που βοηθούν όταν το σχήμα είναι τεράστιο, ή χρωματισμένους πίνακες για κατηγοριοποίηση, κλπ. Άφησα για το τέλος ένα μικρό μυστικό: δεν χρειαζόταν να παιδευτείτε με τις DDL εντολές το κάναμε μόνο για εκπαιδευτικούς λόγους. Θα μπορούσατε να ετοιμάσετε το διάγραμμα από το μενού File, επιλογή New Model και μετά Add Diagram. Στο διάγραμμα να προσθέσετε τους πίνακες με τα πεδία τους και να τους συσχετίσετε μέχρι να μοντελοποιήσετε όλη τη ΒΔ Κατόπιν από το μενού Database, η επιλογή Forward Engineer στον αυτόματο (πατώντας κάμποσα Next) θα σας φτιάξει τον DDL κώδικα που φτιάχνει τη ΒΔ 13, δηλαδή τις εντολές που σας έφαγαν προηγουμένως το χρόνο σας. Βέβαια, αν δείτε τον κώδικα που φτιάχτηκε αυτόματα θα δείτε ότι είναι λεπτομερειακός και λίγο φανφαρόνικος, αλλά παρόλα αυτά κατανοητός και, βέβαια, δίχως τα εκνευριστικά συντακτικά σφάλματα που κάνατε στην πληκτρολόγηση των DDL εντολών. Χώρια η πλάκα τώρα, η δυνατότητα να κινούμαστε από ένα διάγραμμα στον κώδικα DDL και αντίστροφα είναι πολύ χρήσιμη γιατί μας επιτρέπει να βλέπουμε τη ΒΔ με δυο οπτικές. Άσε που υπάρχει και η δυνατότητα να γίνονται οι επιθυμητές αλλαγές στο μοντέλο της ΒΔ και μέσω της λειτουργίας Synchronize Model With Database να γίνεται έλεγχος σε τι διαφέρουν και να παράγεται αυτόματα ο κώδικας με τις απαραίτητες ALTER TABLE. Για παράδειγμα, αν προσθέσουμε ένα πεδίο στον πίνακα istoriko στο διάγραμμα που φαίνεται στην Εικόνα 18 και εκτελέσουμε τη λειτουργία του συγχρονισμού θα παράγει τον κώδικα ALTER TABLE `mageiriki`.`istoriko` ADD COLUMN `new_column` VARCHAR(45) NULL DEFAULT NULL AFTER `protaseis`; Νομίζω ότι με αυτή την μικρή περιγραφή των διαγραμμάτων κατέστρεψα όλη τη χρησιμότητα του να μάθει κανείς να γράφει DDL. Ωραίος τρόπος να κλείσει το κεφάλαιο! 13 Reverse engineer: από το τελικό αποτέλεσμα (κώδικα) στην αρχική προδιαγραφή. Forward engineer: από την προδιαγραφή στον κώδικα που την υλοποιεί. 25-Νοε-16 Σελ. 21

22 7. Ερωτήματα χειρισμού εγγραφών Μετά τη δημιουργία των πινάκων της ΒΔ λογικά ακολουθεί η εισαγωγή εγγραφών. Μέχρι τώρα έχουμε δει ο χειρισμός των εγγραφών, που εκτός από την εισαγωγή, περιλαμβάνει τροποποίηση και διαγραφή, να γίνεται ανοίγοντας τον πίνακα σε πλέγμα γραμμών που αντιστοιχούν στις εγγραφές και στηλών που αντιστοιχούν στα πεδία. Εναλλακτικά, μπορούμε να χρησιμοποιήσουμε ειδικά διαμορφωμένες φόρμες δεδομένων που είναι ο ενδεδειγμένος τρόπος για τον τελικό χρήστη λόγω ελέγχου και απλότητας. Στις επόμενες τρεις ενότητες θα δούμε τις εντολές SQL που εκτελούν χειρισμό εγγραφών. 7.1 Εισαγωγή νέας εγγραφής Η εντολή SQL είναι της μορφής INSERT INTO πίνακας (λίστα-πεδίων) VALUES (λίστα-τιμών) Παραδείγματα εισαγωγής νέων εγγραφών στη ΒΔ : INSERT INTO POLH (TAX_KOD, ONO_POL, PERIFEREIA) VALUES ('84100', 'ΣΥΡΟΣ', 'ΝΟΤΙΟ ΑΙΓΑΙΟ') και απλούστερα, αν βάζουμε τιμές σε όλα τα πεδία του πίνακα INSERT INTO POLH VALUES ('84200', 'ΤΗΝΟΣ', 'ΝΟΤΙΟ ΑΙΓΑΙΟ') Για να εισάγουμε δεδομένα σε συγκεκριμένα πεδία, αφήνοντας τα υπόλοιπα κενά (εφόσον αυτό επιτρέπεται από περιορισμούς NOT NULL), η παραλλαγή είναι: INSERT INTO POLH (TAX_KOD, ONO_POL) VALUES ('50100', 'ΚΟΖΑΝΗ') που προδιαγράφει σε ποια πεδία θα τοποθετηθούν οι τιμές. Απλό, ε; Θυμηθείτε να κλείνετε σε εισαγωγικά τις τιμές των πεδίων τύπου συμβολοσειράς και να εισάγετε τις ημερομηνίες στη μορφή έτος-μήνας-ημέρα, όπως στο παράδειγμα: INSERT INTO ATOMO VALUES ('Σ543789', 'ΑΝΤΩΝΗΣ ΓΡΕΚΟΣ', ' ', 1.79, '50100') Για μεγαλύτερους όγκους δεδομένων, όλα τα ΣΔΒΔ παρέχουν εργαλεία ομαδικής εισαγωγής εγγραφών από αρχεία Excel, XML, ή και (δομημένου) κειμένου όπου οι τιμές των πεδίων είτε έχουν σταθερό πλάτος, είτε χωρίζονται με ειδικούς χαρακτήρες, πχ κόμμα, στηλοθέτη (tab), κ.λπ. Η εκδοχή της INSERT INTO που χρησιμοποιήσαμε μέχρι τώρα περιέχει τη φράση VALUES και εισάγει μόνο μία εγγραφή στον πίνακα. Η εντολή INSERT έχει και μια παραλλαγή που αντί της φράσης VALUES χρησιμοποιεί μια SELECT επιλέγοντας εγγραφές και εισάγοντάς τις ομαδικά. Για παράδειγμα, INSERT INTO πίνακας-στόχος SELECT πεδία FROM πίνακας-πηγή WHERE κριτήριο Αυτή η INSERT θα επιλέξει εγγραφές και πεδία από τον πίνακα πηγή και θα τις εισάγει στον πίνακα στόχο. Για παράδειγμα, έ- στω ότι υπάρχει ένας πίνακας KONTOI INSERT INTO KONTOI SELECT ADT, ONO_ATOM, YPSOS FROM ATOMO WHERE YPSOS >= Διαγραφή εγγραφής Η εντολή SQL για τη διαγραφή εγγραφών είναι DELETE FROM πίνακας WHERE κριτήριο Για παράδειγμα, DELETE FROM POLH WHERE TAX_KOD = '50100' θα σβήσει την Κοζάνη. Προφανώς το DELETE FROM POLH διαγράφει όλες τις εγγραφές του πίνακα. Οι «προχω» γκουρού της SQL θα σας πουν ότι υπάρχει και η εντολή TRUNCATE TABLE POLH για να σβήνεις γρήγορα όλες τις εγγραφές του πίνακα. Μην τη χρησιμοποιήσετε ποτέ! Είναι μια κερκόπορτα που παρακάμπτει ασφαλιστικές δικλείδες του ΣΔΒΔ θυσιάζοντάς τις στο βωμό της ταχύτητας. Τέτοιες μαγκιές να λείπουν. 7.3 Τροποποίηση υπάρχουσας εγγραφής Η τελευταία εντολή της γλώσσας χειρισμού δεδομένων που θα δούμε είναι η UPDATE που τροποποιεί τιμές φτάνει να μην παραβιάζονται οι κανόνες ακεραιότητας του πίνακα. igaviotis@gmail.com 25-Νοε-16 Σελ. 22

23 UPDATE πίνακας SET πεδίο = τιμή WHERE κριτήριο Παραδείγματα: UPDATE POLH SET ONO_POL = 'Σύρα' WHERE TAX_KOD = '84100' που επηρεάζει μια εγγραφή και UPDATE POLH SET PERIFEREIA = 'Νότιο Αιγαίο' WHERE TAX_KOD LIKE '84%' που επηρεάζει όσες εγγραφές ταιριάζουν με το κριτήριο (ξεκινούν με 84). 8. Όψεις Στη ΒΔ οι πληροφορίες είναι αποθηκευμένες σε πίνακες που προκύπτουν με βάση τους κανόνες σχεδίασης που είδαμε στο κεφάλαιο 2, προκειμένου να αποφύγουμε προβλήματα, όπως τα επαναλαμβανόμενα πεδία, και η ασυνέπεια εγγραφών. Αυτό συχνά οδηγεί στον κατακερματισμό της πληροφορίας σε ξεχωριστούς πίνακες που συνδέονται μεταξύ τους με κοινά πεδία. Έτσι για να αντλήσουμε χρήσιμες πληροφορίες χρειάζεται να συνδέσουμε πίνακες με JOIN και το αποτέλεσμα να το τροφοδοτήσουμε σε άλλα ερωτήματα. Για να απλουστεύσουμε αυτή την κατάσταση μπορούμε να ορίσουμε ένα ερώτημα που μας χρειάζεται συχνά ως βάση για άλλους υπολογισμούς, να το ονοματίσουμε και να το χρησιμοποιούμε ως βάση για άλλα ερωτήματα σα να ήταν πίνακας. Τέτοια ερωτήματα ονομάζονται όψεις (views). Μια όψη είναι ένα δυναμικά υπολογιζόμενο σύνολο εγγραφών που προκύπτει από την εκτέλεση ερωτημάτων. Τα αποτελέσματα της εκτέλεσης μιας όψης δεν αποθηκεύονται στη ΒΔ, αφενός για να μη σπαταλιέται αποθηκευτικός χώρος και αφετέρου για να είναι φρέσκα, υπολογισμένα τη στιγμή που θα χρειαστούν. Εκτός από αυτή την ουσιαστική διαφορά, ο χρήστης μπορεί να χειρίζεται το αποτέλεσμα μιας όψης ως έναν πίνακα. Για παράδειγμα, ας πούμε ότι στη ΒΔ ΚΑΤΟΙΚΟΙ (δείτε Εικόνα 17) συχνά ζητούνται στοιχεία για την περιφέρεια που κατοικεί κάθε άτομο και άλλα στοιχεία του. Ας πούμε ότι μας ζητείται να φτιάξουμε ερωτήματα: 1. Βρείτε ποια είναι η πολυπληθέστερη περιφέρεια της χώρας. 2. Βρείτε την ηλικία του γηραιότερου κατοίκου κάθε περιφέρειας. 3. Βρείτε τον μέσο όρο ηλικίας όλων των κατοίκων της. 4. Βρείτε πόσες πόλεις σε κάθε περιφέρεια έχουν πληθυσμό πάνω από Βρείτε την κατανομή των γεννήσεων ανά δεκαετία για κάθε περιφέρεια. Όλα αυτά τα ερωτήματα απαιτούν πληροφορίες που ανήκουν και στους δυο πίνακες POLH και ATOMO. Ο διαχειριστής της ΒΔ αναγνωρίζοντας ότι συχνά ζητούνται στοιχεία ατόμων και της περιφέρειας που κατοικούν μπορεί να ορίσει μια όψη: CREATE VIEW KATOIKOI_PERIFER AS SELECT POLH.PERIFEREIA, ATOMO.* FROM POLH INNER JOIN ATOMO ON ONO_POL = POLH_POU_ZEI Το αποτέλεσμα της όψης KATOIKOI_PERIFER λειτουργεί ως πίνακας με όλα τα πεδία της όψης. Έτσι, «χτίζοντας» πάνω στην όψη φτιάχνουμε το ερώτημα για την πολυπληθέστερη περιφέρεια: SELECT PERIFEREIA, COUNT(ADT) AS PLYTHISMOS FROM KATOIKOI_PERIFER GROUP BY PERIFEREIA ORDER BY PLYTHISMOS DESC Βλέπετε ότι στη σύνταξη του ερωτήματος, η SQL μεταχειρίζεται την όψη σαν να ήταν πίνακας, αλλά στην εκτέλεση του ερωτήματος θα υπολογιστεί πρώτα η όψη και πάνω στο αποτέλεσμά της θα υπολογιστεί η λίστα των πληθυσμών. Μάλιστα, αν χρειαζόταν να δίνουμε τα στοιχεία των πληθυσμών των περιφερειών σε μια υπηρεσία, χωρίς να τους παρέχουμε προσπέλαση στα προσωπικά δεδομένα του ποιο άτομο κατοικεί πού και πότε γεννήθηκε, θα ορίζαμε και το προηγούμενο ερώτημα SELECT ως όψη, προθέτοντας το CREATE VIEW PLYTHISMOS_PERIFEREION AS... και έτσι θα εξασφαλίζαμε ελεγχόμενη πρόσβαση στην πληροφορία των πληθυσμών των περιφερειών και θα απαγορεύαμε την πρόσβαση στις ευαίσθητες πληροφορίες του πίνακα ATOMO. Για την ακρίβεια, αυτός είναι άλλος ένας σημαντικός λόγος που χρησιμοποιούνται οι όψεις: να παρουσιάζουν πληροφορία με την απαιτούμενη μορφή, αποκρύπτοντας στοιχεία που δεν πρέπει ή δεν χρειάζεται να δημοσιευτούν. Για παράδειγμα, σκεφτείτε ότι το τμήμα μισθοδοσίας μιας επιχείρησης διατηρεί σε ένα πίνακα τα στοιχεία των εργαζομένων και μεταξύ αυτών τον μισθό τους. Η διεύθυνση προσωπικού θέλει να γνωρίζει την ημερομηνία γέννησης του κάθε μόνιμου εργαζόμενου, διότι εκείνη την ημέρα δικαιούται αδείας (λέμε τώρα). Σε αυτή την περίπτωση, ο διαχειριστής της ΒΔ θα ορίσει μια όψη στον πίνακα των εργαζομένων, όχι για να τον συνδέσει με κάποιον άλλο πίνακα, αλλά για να αποκόψει πεδία και εγγραφές. CREATE VIEW GENETHLIA AS SELECT ONOMA, HM_GEN igaviotis@gmail.com 25-Νοε-16 Σελ. 23

24 FROM ERGAZOMENOI WHERE APASXOLISI = 'Μόνιμος' Για λόγους πληρότητας, αναφέρουμε την εντολή της Γλώσσας Ορισμού Δεδομένων DROP VIEW GENETHLIA που λειτουργεί κατ' αναλογία με την DROP TABLE. Δηλαδή; Συνοψίζοντας, οι όψεις είναι χρήσιμες για: Ασφάλεια Προσαρμοσμένη πρόσβαση στα δεδομένα Απλοποίηση σύνθετων λειτουργιών σύνδεσης επί των πρωτογενών (αποθηκευμένων) δεδομένων 9. Δικαιώματα προσπέλασης Μια και φέτος ασχολούμαστε με εμπορικά ΣΔΒΔ που υποστηρίζουν μεγάλες ΒΔ θα μιλήσουμε για ασφάλεια που επιβάλλεται με απόδοση δικαιωμάτων και επιβολή αποκλεισμών από συγκεκριμένες λειτουργίες της ΒΔ. Τέτοιες προχωρημένες δυνατότητες παρέχονται μόνο από τα «μεγάλα» ΣΔΒΔ που λειτουργούν ως εξυπηρέτες ΒΔ (database servers). Στα προσωπικά ΣΔΒΔ, του τύπου MS Access, η ασφάλεια επιβάλλεται με πιο απλό τρόπο, πχ με ένα συνθηματικό σε επίπεδο του αρχείου της ΒΔ. Ο στόχος είναι κάθε πιστοποιημένος χρήστης που συνδέεται με τη ΒΔ να μπορεί να εκτελέσει μόνο τις απαραίτητες λειτουργίες για τη διεκπεραίωση της εργασίας του, να υπάρχει ιχνηλάτηση του ποιος εκτέλεσε πότε ποια λειτουργία και τέλος να έχει πρόσβαση στα ελάχιστα δεδομένα που είναι απαραίτητα και να μην «βλέπει» δεδομένα που βρίσκονται μέσα στη ΒΔ, αλλά δεν άπτονται των αρμοδιοτήτων του. Ας ξεκινήσουμε με την αυθεντικοποίηση 14 των προσώπων που συνδέονται με τη ΒΔ. Υπάρχουν αρκετές επιλογές αυθεντικοποίησης, πχ με βάση τον χρήστη που είναι συνδεδεμένος στον υπολογιστή ή στο τοπικό δίκτυο που λειτουργεί η ΒΔ, αλλά το επικρατέστερο είναι να δημιουργήσουμε χρήστες μέσα στη ΒΔ που λειτουργούμε. Αυτό γίνεται σε δυο φάσεις: πρώτα φτιάχνουμε ένα όνομα σύνδεσης (login) σε επίπεδο στιγμιοτύπου του εξυπηρέτη της ΒΔ CREATE LOGIN ANNA WITH PASSWORD = '123' Με την εντολή αυτή δηλώνουμε ότι ο χρήστης μπορεί να συνδεθεί με τον εξυπηρέτη της ΒΔ, εφόσον εισάγει το σωστό συνθηματικό. Βέβαια και που θα συνδεθεί με τον εξυπηρέτη, δεν μπορεί να κάνει πρακτικά τίποτα, διότι δεν έχει δικαίωμα να συνδεθεί με τις ΒΔ που στεγάζονται στον εξυπηρέτη. Έτσι χρειάζεται να ακολουθήσει το επόμενο βήμα. Θα κατασκευάσουμε ένα όνομα χρήστη (user) μέσα στη συγκεκριμένη ΒΔ που μας ενδιαφέρει. Για απλότητα τον ονομάζουμε κι αυτόν ANNA και τον σχετίζουμε με το όνομα σύνδεσης ANNA. USE KATOIKOI CREATE USER ANNA FOR LOGIN ANNA Παρατηρήστε ότι το συνθηματικό ορίζεται στο όνομα σύνδεσης και ισχύει για όλες τις ΒΔ που «στεγάζονται» στον εξυπηρέτη ΒΔ. Έπειτα κατεβαίνουμε σε επίπεδο ΒΔ και ορίζουμε τον χρήστη ANNA να σχετίζεται με το όνομα σύνδεσης ANNA. 14 Αυθεντικοποίηση (authentication) είναι η διαδικασία με την οποία το ΣΔΒΔ επιβεβαιώνει ότι ένας δράστης που αλληλεπιδρά με τη ΒΔ είναι πραγματικά αυτός που ισχυρίζεται ότι είναι. Αυτό επιτυγχάνεται με ένα συνδυασμό ονόματος χρήστη (username) και συνθηματικού (password). igaviotis@gmail.com 25-Νοε-16 Σελ. 24

25 Αν αποσυνδεθούμε από το ΣΔΒΔ και συνδεθούμε ως ANNA και όχι ως Administrator που κάναμε ως τώρα, θα δούμε τις ΒΔ του εξυπηρέτη και μπορούμε να κάνουμε USE KATOIKOI για να συνδεθούμε στη ΒΔ, αλλά και πάλι δεν βλέπουμε ούτε πίνακες, ούτε τίποτα, γιατί δεν έχουμε κανένα δικαίωμα. Το πιο συνηθισμένο σενάριο για να αποδώσουμε δικαιώματα σε χρήστες της ΒΔ είναι να χρησιμοποιήσουμε προκατασκευασμένους ρόλους (roles) που μας παρέχει το ΣΔΒΔ, όπως ιδιοκτήτης, αναγνώστης (δικαιώματα ανάκλησης περιεχομένων από τη ΒΔ, χωρίς δικαίωμα αλλαγών), εγγραφέας (δικαιώματα προσθήκης, τροποποίησης, διαγραφής δεδομένων). Εκτός από τους προκατασκευασμένους ρόλους, υπάρχει δυνατότητα να δημιουργήσουμε / προσαρμόσουμε ρόλους κατά τις ιδιαίτερες ανάγκες μας. Αν όμως επιθυμείτε πιο λεπτομερειακή απόδοση δικαιωμάτων, διαβάστε παρακάτω. Ας δούμε τώρα αναλυτικά πως δίνουμε διάφορα δικαιώματα προσπέλασης στον χρήστη ANNA. Συνδεδεμένοι ως διαχειριστές, μπορούμε να εκτελέσουμε την εντολή GRANT SELECT, INSERT, UPDATE, DELETE TO ANNA που δίνει στην ΑΝΝΑ δικαίωμα να εκτελεί επιλογές, εισαγωγές, ενημερώσεις και διαγραφές εγγραφών σε όλους τους πίνακες της ΒΔ. Αντίθετα, η εντολή REVOKE αφαιρεί δικαιώματα, πχ REVOKE DELETE FROM ANNA θα απαγορεύσει τις διαγραφές από όλους τους πίνακες για την ANNA. Αν επιθυμούμε η ANNA να έχει δικαιώματα μόνο ανάγνωσης χωρίς δικαιώματα τροποποίησης μπορούμε να της αφαιρέσουμε όλα τα δικαιώματα, και μετά να προσθέσουμε το δικαίωμα SELECT REVOKE ALL FROM ANNA GRANT SELECT TO ANNA Αυτές οι εντολές λειτουργούν για ολόκληρη τη ΒΔ. Αν είμαστε λεπτολόγοι, θα θέλουμε να αποδώσουμε ξεχωριστά δικαιώματα για κάθε αντικείμενο της ΒΔ. Οι εντολές GRANT SELECT, INSERT, UPDATE ON ATOMO TO ANNA REVOKE DELETE ON POLH TO ANNA λειτουργούν πάνω σε πίνακες όχι σε ολόκληρη τη ΒΔ. Η γενική σύνταξη των εντολών απόδοσης και αφαίρεσης δικαιωμάτων σε αντικείμενα της ΒΔ είναι: GRANT δικαίωμα ON αντικείμενο TO χρήστης REVOKE δικαίωμα ON αντικείμενο FROM χρήστης όπου δικαίωμα είναι μια από τις λέξεις SELECT, INSERT, UPDATE, DELETE, αντικείμενο είναι κάποιος πίνακας ή και όψη (view) και βέβαια χρήστης είναι ένας user (όχι όνομα σύνδεσης, login) που έχει οριστεί μέσα στη ΒΔ. Οι εντολές που είδαμε σε ευτή την ενότητα συνιστούν τη Γλώσσα Ασφάλειας Δεδομένων (Data Security Language). Ανακεφαλαιώνοντας για το θέμα της ασφάλειας, για να μπορέσεις να προσπελάσεις δεδομένα σε μια ΒΔ πρέπει να περάσεις από δυο στάδια αυθεντικοποίησης, πρώτα να σε αναγνωρίζει η εγκατάσταση του ΣΔΒΔ με ένα νόμιμο όνομα σύνδεσης (login) και συνθηματικό και έπειτα να έχεις κατάλληλα δικαιώματα στη ΒΔ που θέλεις να συνδεθείς ως χρήστης (user) 15. Από κει και πέρα ο διαχειριστής έχει καθορίσει τα δικαιώματα που έχεις ανά αντικείμενο. 10. Διαδικαστική SQL Μερικές φορές χρειάζεται να αναμίξουμε εντολές SQL με εντολές ανάθεσης, IF και άλλες δομές που κανονικά συναντάμε σε μια διαδικαστική γλώσσα προγραμματισμού. Το υποσύνολο της SQL που περιλαμβάνει αυτές τις εντολές λέγεται Γλώσσα Ελέγχου Προγραμματισμού (Programming Control Commands). Ας ξεκινήσουμε δηλώνοντας μεταβλητές και αναθέτοντας τους τιμές. Οι μεταβλητές στην διαδικαστική SQL δηλώνονται με την DECLARE και το όνομά τους ξεκινά DECIMAL(5,0); = 84100; --τυπώνει την τιμή της μεταβλητής Η ανάθεση γίνεται με την εντολή SET και η εκτύπωση της τιμής γίνεται με την εντολή SELECT ή την PRINT. Στον κώδικα που ακολουθεί χρησιμοποιείται η τιμή της μεταβλητής στο ερώτημα SELECT. USE KATOIKOI; SELECT * FROM POLH WHERE TAX_KOD Κατά την εκτέλεσή του εμφανίζει τις εγγραφές του πίνακα που έχουν TAX_KOD= Ας προσθέσουμε και μια IF USE KATOIKOI; DELETE FROM ATOMO WHERE POLH_POU_ZEI > 0 BEGIN 15 Συνήθως, αντιστοιχίζουμε το όνομα σύνδεσης με το συνώνυμο όνομα χρήστη, όπως σε όλα τα παραδείγματα των σημειώσεων. Αυτό δεν είναι απαραίτητο, θα μπορούσε το login να είναι διαφορετικό από το user. Ακόμα θα μπορούσε το ίδιο login να σχετίζεται με πολλούς user, αλλά έναν σε κάθε ΒΔ. igaviotis@gmail.com 25-Νοε-16 Σελ. 25

26 PRINT 'Διαγράφηκαν ' + ' κάτοικοι της πόλης με ΤΚ ' END DELETE FROM POLH WHERE TAX_KOD είναι μια μεταβλητή του ΣΔΒΔ που μετράει πόσες εγγραφές επηρεάστηκαν από την εκτέλεση της προηγούμενης εντολής SQL. Μια και φτάσαμε στο σημείο να έχουμε πολλές εντολές SQL μαζεμένες που εκτελούν ένα καθήκον και μπορεί να επιθυμούμε να λειτουργούν και ως ενιαία δοσοληψία, ας δούμε πώς μπορούμε να τους δώσουμε ένα όνομα και να τις μετατρέψουμε αυτό που οι κλασικές γλώσσες προγραμματισμού ονομάζουν υπορουτίνες και η SQL ονομάζει αποθηκευμένες διαδικασίες (stored procedures). CREATE PROCEDURE SP_APLO AS BEGIN SELECT * FROM ATOMO INNER JOIN POLH ON POLH.TAX_KOD = ATOMO.POLH_POU_ZEI END είναι μια αποθηκευμένη διαδικασία που φυλάσσεται μέσα στη ΒΔ, μεταγλωττισμένη 16 και έτοιμη για εκτέλεση. Για να την καλέσουμε, η εντολή είναι EXEC SP_APLO Ας δούμε και άλλο ένα παράδειγμα που έχει και παραμέτρους. CREATE PROCEDURE INT AS BEGIN = 1 -μέτριος UPDATE ERGAZOM SET MISTHOS = MISTHOS * 1.10 WHERE KOD_ERGAZOM ELSE --άριστος UPDATE ERGAZOM SET MISTHOS = MISTHOS * 1.20 WHERE KOD_ERGAZOM END Και για να εκτελεστεί EXEC = = 1 Στα παραδείγματα αυτής της ενότητας είδαμε την επέκταση της κανονικής SQL με εντολές που ανήκουν στην διαδικαστική SQL (το ΣΔΒΔ SQL Server, από το οποίο είναι τα παραδείγματα, την ονομάζει T-SQL και το ΣΔΒΔ Oracle την ονομάζει PL/SQL). Ωστόσο, είναι δυνατόν να ενσωματώσουμε εντολές SQL σε μια κανονική διαδικαστική γλώσσα προγραμματισμού, όπως C, Java και άλλες για να υλοποιήσουμε πολύπλοκες λειτουργίες. Αυτό το μείγμα εντολών SQL και εντολών διαδικαστικής γλώσσας, ονομάζεται ενσωματωμένη SQL (embedded SQL)και ένα παράδειγμα του βλέπουμε στην Εικόνα Δοσοληψίες Ας πούμε ότι μια τράπεζα διατηρεί σε μια ΒΔ τα στοιχεία των λογαριασμών καταθέσεων (δείτε το απλοϊκό σχήμα στην Εικόνα 20) και θέλετε να μεταφέρετε 5 ευρώ ανάμεσα στους δυο λογαριασμούς του Ανδρέου. Η λειτουργία αυτή υλοποιείται με δυο συνεχόμενες εντολές SQL ως εξής: UPDATE LOGAR SET YPOLOIPO = YPOLOIPO 5 WHERE ARLOG = '1234' UPDATE LOGAR SET YPOLOIPO = YPOLOIPO + 5 int main() { EXEC SQL INCLUDE SQLCA; EXEC SQL BEGIN DECLARE SECTION; int OrderID; /* αρ παραγγ (από χρήστη) */ int CustID; /* αρ πελάτη */ char SalesPerson[10] /* όνομα πωλητή */ char Status[6] /* κατάσταση παραγγελίας */ EXEC SQL END DECLARE SECTION; } /* ο χρήστης εισάγει τον αριθμό παραγγελίας */ printf ("Enter order number: "); scanf_s("%d", &OrderID); /* εκτέλεση ερωτήματος SQL */ EXEC SQL SELECT CustID, SalesPerson, Status FROM Orders WHERE OrderID = :OrderID INTO :CustID, :SalesPerson, :Status; /* προβολή αποτελεσμάτων */ printf ("Αρ πελάτη: %d\n", CustID); printf ("Πωλητής: %s\n", SalesPerson); printf ("Κατάσταση: %s\n", Status); Εικόνα 19 Ενσωματωμένη SQL σε C USE TRAPEZA CREATE TABLE LOGAR ( ARLOG DECIMAL(4,0) PRIMARY KEY, DIKAIOUX NVARCHAR(40) NOT NULL, YPOLOIPO DECIMAL(8,2) NOT NULL CHECK(YPOLOIPO>=0.00) ) INSERT INTO LOGAR VALUES (1234, 'Ανδρέου Ανδρέας', 50.00) 16 Και μάλιστα όχι απλώς μεταγλωττισμένη, αλλά INSERT και βελτιστοποιημένη, INTO LOGAR VALUES αφού δημιουργούνται (2345, 'Νικολάου πλάνα εκτέλεσης Νίκος', που 10.11) λαμβάνουν υπόψη τα αντικείμενα (πχ πίνακες) που συμμετέχουν INSERT στην INTO εκτέλεση LOGAR και VALUES τεχνικές (4321, λεπτομέρειες 'Ανδρέου του μεγέθους, Ανδρέας', του τρόπου 94.80) αποθήκευσης (πχ ευρετήρια). igaviotis@gmail.com 25-Νοε-16 Εικόνα 20 Βάση δεδομένων TRAPEZA Σελ. 26