ΒΑΣΕΙΣ ΔΕΔΟΜΕΝΩΝ Ι Σημειώσεις διάλεξης

Transcript

1 ΒΑΣΕΙΣ ΔΕΔΟΜΕΝΩΝ Ι Σημειώσεις διάλεξης Νίκος Αντωνιάδης Καθηγητής Απρίλιος 2016 ΤΕΙ Ηπείρου Τμήμα Μηχανικών Πληροφορικής ΤΕ

2 Σφάλματα: Σε όλα τα σημεία όπου αναφέρεται η φυσική σύνδεση (natural join) μεταξύ πινάκων, το σωστό σύμβολο είναι και όχι το σύμβολο που εμφανίζεται λανθασμένα στην εκτύπωση.

3 1 Εισαγωγή Ενα σύστημα διαχείρισης βάσεων δεδομένων (Database Management System, DBMS) αποτελείται από μια συλλογή συσχετιζόμενων δεδομένων και ένα σύνολο προγραμμάτων που δίνουν πρόσβαση στα δεδομένα. Η βάση δεδομένων είναι το σύνολο των δεδομένων που αφορούν μια συγκεκριμένη επιχείρηση, οργανισμό, κτλ. Ο κύριος σκοπός ενός DBMS είναι να παρέχει ένα περιβάλλον μέσα στο οποίο η αποθήκευση, επεξεργασία και ανάκτηση των δεδομένων είναι εύκολη, γρήγορη και αποτελεσματική. Τα συστήματα βάσεων δεδομένων έχουν σκοπό το χειρισμό μεγάλης ποσότητας πληροφορίας. Ο χειρισμός αυτός περιλαμβάνει λειτουργίες όπως η αποθήκευση, η δημιουργία των κατάλληλων δομών, η δημιουργία μηχανισμών πρόσβασης, καθώς και η ασφάλεια των δεδομένων και η προστασία τους από τυχαίες ή και κακόβουλες παρεμβάσεις. Η ολοένα και αυξανόμενη σημασία της πληροφορίας για τις σημερινές επιχειρήσεις και οργανισμούς έχει δημιουργήσει την ανάγκη για την ανάπτυξη ιδεών και τεχνικών για την αποδοτική διαχείριση των δεδομένων. Στο κεφάλαιο αυτό παρουσιάζονται οι βασικές εισαγωγικές ιδέες των συστημάτων βάσεων δεδομένων. 1.1 Σκοπός των Συστημάτων Βάσεων Δεδομένων Θεωρούμε ένα τμήμα ενός τραπεζικού συστήματος το οποίο κρατάει και διαχειρίζεται πληροφορίες σχετικά με τους πελάτες και τους τραπεζικούς τους λογαριασμούς. Το τμήμα αυτό έχει στη διάθεση του και κάποια προγράμματα εφαρμογών, τα οποία δίνουν στο χειριστή διάφορες δυνατότητες: Μια εφαρμογή για χρέωση και πίστωση του λογαριασμού Μια εφαρμογή για πρόσθεση νέου λογαριασμού Μια εφαρμογή για εύρεση του υπολοίπου του λογαριασμού Μια εφαρμογή για τη δημιουργία μηνιαίων αντιγράφων κίνησης του λογαριασμού. Αυτές οι εφαρμογές έχουν γραφεί από προγραμματιστές, σύμφωνα με τις προδιαγραφές που έχει δώσει η Τράπεζα, ώστε να καλύπτονται οι ανάγκες της λειτουργίας της. Αν οι ανάγκες αυτές αυξάνονται ή τροποποιούνται, πρέπει να προστεθούν νέες εφαρμογές ή να τροποποιηθούν οι παλιότερες. Για παράδειγμα, αν υποτεθεί ότι οι νέοι νόμοι επιτρέπουν το άνοιγμα λογαριασμών με αρνητικό υπόλοιπο από όλους τους πελάτες, τότε πρέπει να τροποποιηθούν κάποιες εφαρμογές. Εάν δημιουργηθεί η δυνατότητα να ανοίγονται λογαριασμοί οι οποίοι θα λειτουργούν ταυτόχρονα και σε άλλες χώρες, πρέπει να γραφεί μια εφαρμογή που να χειρίζεται αυτή την ειδική περίπτωση. Αυτό έχει σαν αποτέλεσμα νέες εφαρμογές και νέα αρχεία να προστίθενται στο σύστημα. Σε ένα παραδοσιακό σύστημα επεξεργασίας αρχείων, τα δεδομένα κρατούνται σε διάφορα αρχεία και οι εφαρμογές έχουν πρόσβαση σε αυτά τα αρχεία ώστε να αποθηκεύουν και να ανακτούν δεδομένα ανάλογα με τη ζήτηση. Αυτό το σχήμα έχει διάφορα προβλήματα και μειονεκτήματα:

4 Πλεονασμός (redundancy) και ασυμβατότητα (inconsistency) δεδομένων: οι εφαρμογές γράφονται σε διαφορετικές χρονικές στιγμές, πιθανόν από διαφορετικούς προγραμματιστές και σε διαφορετικές γλώσσες. Οι ίδιες πληροφορίες μπορεί να αποθηκεύονται σε διαφορετικές θέσεις περισσότερες από μία φορές. Για παράδειγμα, η διεύθυνση και ο αριθμός τηλεφώνου ενός πελάτη μπορεί να καταγράφεται τόσο στο αρχείο των λογαριασμών όψεως όσο και στο αρχείο των λογαριασμών ταμιευτηρίου. Αυτό συνεπάγεται υψηλότερο κόστος και σπατάλη πόρων. Επίσης, είναι δυνατό να προκληθεί ασυμβατότητα αργότερα, καθώς τυχόν αλλαγή των στοιχείων είναι πιθανό να αποθηκευθεί μόνο στο ένα σημείο αποθήκευσης και όχι στα υπόλοιπα. Δυσκολίες πρόσβασης στα δεδομένα: ας υποτεθεί ότι κάποια στιγμή χρειάζεται να παραχθεί ένας κατάλογος των πελατών οι οποίοι κατοικούν σε μια συγκεκριμένη πόλη. Αυτό δεν είχε προβλεφθεί όταν σχεδιάστηκε και υλοποιήθηκε το σύστημα (κάτι που είναι φυσιολογικό), αντίθετα δημιουργήθηκε μια εφαρμογή η οποία παράγει έναν κατάλογο όλων των πελατών. Πρέπει λοιπόν είτε να δημιουργηθεί η λίστα αυτή και ακολούθως να απομονωθούν τα στοιχεία που ενδιαφέρουν, είτε να γραφεί μια εφαρμογή που να κάνει αυτή ακριβώς την εργασία. Και οι δύο λύσεις προφανώς δεν είναι ικανοποιητικές. Για τη δεύτερη λύση, μπορεί κανείς να δει εύκολα ότι η ίδια ανάγκη θα προκύψει όταν ζητηθεί κάτι έστω και ελάχιστα διαφορετικό (π.χ. πελάτες με υπόλοιπο λογαριασμού πάνω από 10 χιλιάδες ευρώ). Ανωμαλίες ταυτόχρονης πρόσβασης (concurrent access): πολλά υπολογιστικά συστήματα επιτρέπουν ταυτόχρονη πρόσβαση και ενημέρωση από διαφορετικές πηγές. Ενα απλό παράδειγμα είναι η εκτέλεση πράξεων σε ένα λογαριασμό από δύο διαφορετικούς κατόχους του λογαριασμού. Αν αυτές οι πράξεις γίνουν σχεδόν ταυτόχρονα, είναι πιθανόν να μην γίνει σωστά η ενημέρωση του λογαριασμού. Στα δεδομένα έχουν συνήθως πρόσβαση πολλές διαφορετικές εφαρμογές οι οποίες πιθανότατα δεν έχουν συντονιστεί προηγουμένως, η επιτήρηση και ο έλεγχος τους είναι επομένως πολύ δύσκολοι. Προβλήματα ασφάλειας: Δεν πρέπει κάθε χρήστης του συστήματος να έχει πρόσβαση σε όλα τα δεδομένα. Οι υπάλληλοι της μισθοδοσίας πρέπει να έχουν πρόσβαση μόνο σε ό, τι αφορά την πληρωμή των υπαλλήλων της Τράπεζας και όχι σε στοιχεία που αφορούν τους λογαριασμούς των πελατών. Επίσης οι υπάλληλοι της Τράπεζας δεν πρέπει να βέπουν στοιχεία που αφορούν τη μισθοδοσία άλλων συναδέλφων τους. Αν οι εφαρμογές είναι ανεξάρτητες, δεν είναι εύκολο να εφαρμοστούν τέτοιοι περιορισμοί ασφαλείας. Προβλήματα αρτιότητας (integrity): τα δεδομένα πρέπει γενικά να υπακούουν σε συγκεκριμένους περιορισμούς συμβατότητας (consistency constraints). Για παράδειγμα, δεν επιτρέπεται ο λογαριασμός ταμιευτηρίου να έχει αρνητικό υπόλοιπο. Επίσης, δεν είναι δυνατόν σε θέσεις που αφορούν χρηματικά ποσά να καταχωρούνται αλφαβητικοί χαρακτήρες, ακόμη και κατά λάθος. Αυτοί οι περιορισμοί υλοποιούνται με τμήματα κώδικα μέσα από τις εφαρμογές. Ωστόσο είναι δύσκολη η διαχείριση και η

5 τροποποίηση τέτοιων περιορισμών καθώς και η προσθήκη νέων, αν τα δεδομένα είναι διασκορπισμένα σε διάφορα αρχεία. Αυτές οι δυσκολίες (καθώς και άλλες πιο εξειδικευμένες που δεν αναφέρονται εδώ) οδήγησαν στη δημιουργία συστημάτων βάσεων δεδομένων. Στο υπόλοιπο αυτών των σημειώσεων, περιγράφονται οι βασικές ιδέες και αλγόριθμοι που έχουν αναπτυχθεί για συστήματα βάσεων δεδομένων, ώστε να δοθεί μια λύση στα προβλήματα που αναφέρθηκαν παραπάνω. 1.2 Αφαίρεση δεδομένων Ενα σύστημα διαχείρισης βάσεων δεδομένων είναι μια συλλογή αλληλοσχετιζόμενων αρχείων και ένα σύνολο προγραμμάτων που επιτρέπουν την πρόσβαση στο χρήστη. Ενας από τους σημαντικότερους στόχους ενός συστήματος βάσεων δεδομένων είναι η διαμόρφωση μιας αφαιρετικής άποψης (abstract view) των δεδομένων που βλέπει ο τελικός χρήστης. Οι περισσότεροι χρήστες μιας βάσης δεδομένων δεν έχουν το επίπεδο γνώσεων, που τους επιτρέπει να καταλάβουν την πολύπλοκη δομή των δεδομένων, κάτι που είναι σε πολλές περιπτώσεις και ανεπιθύμητο. Για το σκοπό αυτό, το σύστημα σχεδιάζεται έτσι ώστε να κρύβει τη λεπτομέρεια του συστήματος σε διάφορα επίπεδα. Φυσικό επίπεδο: Το χαμηλότερο επίπεδο αφαίρεσης, όπου περιγράφεται το πώς πραγματικά αποθηκεύονται τα δεδομένα. Εδώ οι δομές δεδομένων χαμηλού επιπέδου περιγράφονται με λεπτομέρεια. Εννοιολογικό επίπεδο: Το αμέσως υψηλότερο επίπεδο αφαίρεσης περιγράφει τι δεδομένα αποθηκεύονται στη βάση και ποιες είναι οι σχέσεις μεταξύ τους. Περιγράφεται ολόκληρη η βάση δεδομένων με σχετικά απλές δομές. Ο χρήστης αυτού του επιπέδου δεν χρειάζεται να ξέρει το φυσικό επίπεδο. Στο επίπεδο αυτό, δουλεύουν και οι διαχειριστές των βάσεων. Εποπτικό επίπεδο: Το υψηλότερο επίπεδο αφαίρεσης περιγράφει μόνο ένα τμήμα της βάσης. Ακόμα και στο προηγούμενο επίπεδο, η βάση παραμένει περίπλοκη. Ο τελικός χρήστης δεν χρειάζεται αυτή την πολυπλοκότητα αλλά μόνο ένα μέρος της βάσης. Το σύστημα δίνει διάφορα μέρη της βάσης σε διαφορετικούς χρήστες σε αυτό το επίπεδο. Η σχέση των τριών αυτών επιπέδων φαίνεται στο σχήμα Μοντέλα δεδομένων Η βάση της δομής μιας βάσης δεδομένων είναι η ιδέα του μοντέλου δεδομένων, ενός συνόλου εργαλείων για την περιγραφή των δεδομένων, των μεταξύ τους σχέσεων και των τυχόν περιορισμών τους. Τα μοντέλα αυτά χωρίζονται γενικά σε τρεις μεγάλες κατηγορίες: λογικά μοντέλα αντικειμένων (object-based logical models), λογικά μοντέλα εγγραφών (record-based logical models) και μοντέλα φυσικών δεδομένων (physical data models) Λογικά Μοντέλα Αντικειμένων Αυτά χρησιμοποιούνται για την περιγραφή των δεδομένων στα δύο ανώτερα επίπεδα. Υπάρχουν πολλά διαφορετικά μοντέλα και συνεχώς προτείνονται νέα. Μερικά από τα πιο διαδεδομένα είναι:

6 Εποψη 1 Εποψη 2 Εποψη 3 Εννοιολογικό επίπεδο Φυσικό επίπεδο Σχήμα 1.1 Τα τρία επίπεδα της αφαίρεσης δεδομένων Το μοντέλο οντοτήτων-συσχετίσεων (Entity-Relationship Model) Το αντικειμενοστραφές μοντέλο (object-oriented model) Το δυαδικό μοντέλο Το μοντέλο σημασιολογικών δεδομένων Το πληροφοριακό μοντέλο Το μοντέλο λειτουργικών δεδομένων Στις σημειώσεις αυτές, εξετάζονται το μοντέλο οντοτήτων-συσχετίσεων και το αντικειμενοστραφές μοντέλο. Παρακάτω περιγράφονται συνοπτικά. Μοντέλο οντοτήτων-συσχετίσεων Το μοντέλο οντοτήτων-συσχετίσεων (E-R) βασίζεται στην ιδέα μιας συλλογής βασικών αντικειμένων που ονομάζονται οντότητες και των σχέσεων μεταξύ τους. Οντότητα είναι ένα αντικείμενο διακριτό από τα άλλα αντικείμενα μέσω ενός συγκεκριμένου συνόλου χαρακτηριστικών (attributes). Για παράδειγμα, τα χαρακτηριστικά αριθμός-λογαριασμού και υπόλοιπο περιγράφουν έναν συγκεκριμένο τραπεζικό λογαριασμό. Η σχέση είναι μια σύνδεση μεταξύ διαφορετικών οντοτήτων. Για παράδειγμα, μπορεί να δημιουργηθεί μια σχέση Πελ-Λογ, η οποία συνδέει κάθε πελάτη με όσους λογαριασμούς αυτός κατέχει. Το σύνολο των οντοτήτων ίδιου τύπου ονομάζεται σύνολο οντοτήτων και το σύνολο των σχέσεων ίδιου τύπου ονομάζεται σύνολο σχέσεων. Η λογική δομή μιας βάσης δεδομένων μπορεί να παρασταθεί γραφικά με το διάγραμμα E-R, το οποίο αποτελείται από τις παρακάτω συνιστώσες: Ορθογώνια, τα οποία παριστάνουν σύνολα οντοτήτων, Ελλείψεις, οι οποίες παριστάνουν χαρακτηριστικά, Ρόμβους, οι οποίοι παριστάνουν σχέσεις μεταξύ συνόλων οντοτήτων και

7 Γραμμές, οι οποίες συνδέουν τα χαρακτηριστικά με τα σύνολα οντοτήτων και τα σύνολα οντοτήτων με τις σχέσεις. Κάθε συνιστώσα έχει την ετικέτα της οντότητας ή της σχέσης που παριστάνει. Μέρος του τραπεζικού συστήματος το οποίο αναφέρθηκε νωρίτερα και το οποίο θα επεξεργαστούμε στη συνέχεια αυτών των σημειώσεων παριστάνεται με ένα διάγραμμα E-R στο Σχήμα 1.2. όνομα οδός πόλη αριθμός υπόλοιπο Πελάτης Πελ-Λογ Λογαριασμός Σχήμα 1.2 Ενα υπόδειγμα διαγράμματος E-R Το Αντικειμενοστραφές Μοντέλο Οπως και το μοντέλο E-R, το αντικειμενοστραφές μοντέλο βασίζεται σε μια συλλογή αντικειμένων. Ενα αντικείμενο περιέχει τιμές οι οποίες αποθηκεύονται σε στιγμιαίες μεταβλητές (instance variables) μέσα στο αντικείμενο. Αυτές οι τιμές είναι και οι ίδιες αντικείμενα και αυτό το φώλιασμα μπορεί να συνεχιστεί απεριόριστα μέσα στο ίδιο αντικείμενο. Ενα αντικείμενο μπορεί επίσης να περιέχει τμήματα κώδικα, τα οποία ονομάζονται μέθοδοι και τα οποία δρουν πάνω στο αντικείμενο ή σε άλλα αντικείμενα. Αντικείμενα που περιέχουν τους ίδιους τύπους τιμών και τις ίδιες μεθόδους ομαδοποιούνται σε κλάσεις. Για την επικοινωνία μεταξύ αντικειμένων, απαιτείται η αποστολή μηνυμάτων από το ένα στο άλλο, έτσι ώστε να ξεκινήσει κάποια μέθοδος του δεύτερου αντικειμένου. Ετσι, η διεπαφή του μηνύματος καθορίζει και το ορατό τμήμα του αντικειμένου, ενώ το υπόλοιπο τμήμα μένει αθέατο, ορίζοντας έτσι τα επίπεδα αφαίρεσης. Το μοντέλο αυτό παρουσιάζει πολλές αναλογίες με τον αντικειμενοστραφή προγραμματισμό και τις αντίστοιχες γλώσσες προγραμματισμού. Αντίθετα με το μοντέλο E-R, στο αντικειμενοστραφές μοντέλο κάθε αντικείμενο έχει τη δική του «ταυτότητα», ανεξάρτητα από τις τιμές τις οποίες περιέχει. Δύο αντικείμενα που περιέχουν τις ίδιες τιμές είναι απολύτως διακριτά μεταξύ τους. Η διάκριση μεταξύ τους γίνεται στο φυσικό επίπεδο, αλλά είναι πέρα από το αντικείμενο αυτών των σημειώσεων. Σαν ένα παράδειγμα για να κατανοηθεί η ιδέα του μοντέλου, μπορούμε να θεωρήσουμε ένα αντικείμενο το οποίο παριστάνει έναν τραπεζικό λογαριασμό. Περιέχει τις μεταβλητές αριθμός και υπόλοιπο, οι οποίες παριστάνουν τον αριθμό του λογαριασμού και το υπόλοιπο του κάθε χρονική στιγμή. Για τον υπολογισμό του τόκου, περιέχει μια μέθοδο πληρωμή-τόκου, η οποία προσθέτει σε καθορισμένες χρονικές στιγμές τόκο στον λογαριασμό. Αν το επιτόκιο χρειαστεί να αλλάξει, η μόνη αλλαγή που πρέπει να γίνει είναι στον κώδικα της μεθόδου πληρωμή-τόκου, ενώ στα περισσότερα γνωστά

8 μοντέλα δεδομένων η αλλαγή αυτή θα απαιτούσε αλλαγές σε περισσότερα από ένα προγράμματα Λογικά Μοντέλα Εγγραφών Αυτά τα μοντέλα χρησιμοποιούνται για την περιγραφή των δεδομένων στα δύο υψηλότερα επίπεδα αφαίρεσης. Εχουν σκοπό τον καθορισμό της λoγικής δομής της βάσης και την παροχή μιας περιγραφής της υλοποίησης σε υψηλότερο επίπεδο. Η ονομασία των μοντέλων αυτών προέρχεται από το γεγονός ότι η βάση αποτελείται από εγγραφές σταθερής μορφής διαφόρων τύπων. Κάθε εγγραφή αποτελείται από συγκεκριμένα πεδία (θέσεις πίνακα) που έχουν συγκεκριμένο μήκος και τύπο. Τα τρία πιο γνωστά μοντέλα δεδομένων είναι το σχεσιακό, το δικτυακό και το ιεραρχικό. Το σχεσιακό έχει αναδειχθεί σε «δημοφιλέστερο» τα τελευταία χρόνια και εξετάζεται αναλυτικά στη συνέχεια των σημειώσεων. Τα άλλα δύο χρησιμοποιούνται σε παλιότερα συστήματα. Μια συνοπτική παρουσίαση των μοντέλων γίνεται παρακάτω. Σχεσιακό μοντέλο Το σχεσιακό μοντέλο παριστάνει τα δεδομένα και τις σχέσεις μεταξύ τους με πίνακες που έχουν ο καθένας έναν αριθμό στηλών με μοναδικά ονόματα. Μια απλή βάση δίνεται στο Σχήμα 1.3, το οποίο δείχνει τους πελάτες και τους λογαριασμούς τους. Εκεί φαίνεται, για παράδειγμα, ότι ο πελάτης Πέτρου μένει στην οδό Σόλωνος στην Αθήνα και κατέχει δύο λογαριασμούς, με αριθμούς 900 και 905 αντίστοιχα. Παρατηρήστε ότι ο Παύλου και ο Γεωργίου έχουν έναν κοινό λογαριασμό. Όνομα Οδός Πόλη Αριθμός Πέτρου Σόλωνος Αθήνα 900 Πέτρου Σόλωνος Αθήνα 905 Παύλου Λαναρά Λάρισα 908 Γεωργίου Ηρας Βόλος 908 Αθανασίου Βενιζέλου Θεσ/νίκη 910 Παύλου Λαναρά Λάρισα 912 Αριθμός Υπόλοιπο Σχήμα 1.3 Ενα υπόδειγμα σχεσιακής βάσης δεδομένων

9 Δικτυακό μοντέλο Στο δικτυακό μοντέλο, τα δεδομένα παριστάνονται με συλλογές από εγγραφές και οι σχέσεις ανάμεσα στα δεδομένα παριστάνονται από συνδέσμους, οι οποίοι μπορούν να θεωρηθούν δείκτες. Οι εγγραφές της βάσης μπορούν να οργανωθούν σαν συλλογές αυθαίρετων γραφημάτων. Οι πληροφορίες του Σχήματος 1.3 στο δικτυακό μοντέλο θα έδιναν μια παράσταση όπως αυτή του Σχήματος 1.4. Πέτρου Σόλωνος Αθήνα Παύλου Λαναρά Λάρισα Γεωργίου Ηρας Βόλος Σχήμα 1.4 Ενα υπόδειγμα μιας δικτυακής βάσης δεδομένων Ιεραρχικό Μοντέλο Η ιδέα του ιεραρχικού μοντέλου είναι η ίδια με αυτήν του δικτυακού μοντέλου, καθώς και εδώ χρησιμοποιούνται εγγραφές και σύνδεσμοι. Η διαφορά βρίσκεται στο ότι οι εγγραφές οργανώνονται σαν δέντρο και όχι σαν αυθαίρετο γράφημα. Το παραπάνω παράδειγμα με τη μορφή ιεραρχικής βάσης φαίνεται στο Σχήμα 1.5. Πέτρου Σόλωνος Αθήνα Γεωργίου Ηρας Βόλος Παύλου Λαναρά Λάρισα Σχήμα 1.5 Ενα υπόδειγμα μιας ιεραρχικής βάσης δεδομένων 1.4 Στιγμιότυπα και Σχήματα Οι βάσεις δεδομένων αλλάζουν με το χρόνο, καθώς γίνεται εισαγωγή, διαγραφή και τροποποίηση των δεδομένων. Οι πληροφορίες που βρίσκονται μια δεδομένη χρονική στιγμή αποθηκευμένες στη βάση ονομάζονται στιγμιότυπο (instance) της βάσης δεδομένων. Η συνολική σχεδίαση της βάσης ονομάζεται σχήμα της βάσης. Το σχήμα αλλάζει πολύ σπάνια, και μόνο για σοβαρούς λόγους (π.χ. αλλαγή της δομής της εταιρείας, διαγραφή στοιχείων για λόγους απορρήτου, κτλ.).

10 Η έννοια του σχήματος μιας βάσης δεδομένων αντιστοιχεί στον ορισμό τύπου σε μια γλώσσα προγραμματισμού. Μια μεταβλητή ενός συγκεκριμένου τύπου έχει μια συγκεκριμένη τιμή σε μια δεδομένη χρονική στιγμή. Αυτή η τιμή αντιστοιχεί στην έννοια του στιγμιότυπου σε μια βάση δεδομένων. 1.5 Γλώσσα Ορισμού Δεδομένων (Data Definition Language, DDL) Ενα σχήμα βάσης δεδομένων καθορίζεται από ένα σύνολο ορισμών οι οποίοι εκφράζονται από μια ειδική γλώσσα, τη Γλώσσα Ορισμού Δεδομένων (Data Definition Language, DDL). Οι δηλώσεις DDL μεταφράζονται και το αποτέλεσμα είναι ένα σύνολο πινάκων οι οποίοι αποθηκεύονται σε ένα ειδικό αρχείο, το λεξικό δεδομένων (data dictionary) ή κατάλογος δεδομένων (data directory). Ενας κατάλογος δεδομένων είναι ένα αρχείο το οποίο περιέχει μεταδεδομένα (metadata), δηλαδή «δεδομένα σχετικά με δεδομένα». Πριν γίνει οποιαδήποτε προσπέλαση των δεδομένων (είτε για ανάγνωση, είτε για μετατροπή), ο υπολογιστής συμβουλεύεται αυτό το αρχείο. 1.6 Γλώσσα Χειρισμού Δεδομένων (Data Manipulation Language, DML) Ο όρος «χειρισμός δεδομένων» περιλαμβάνει: Ανάκτηση αποθηκευμένης πληροφορίας Εισαγωγή νέας πληροφορίας Διαγραφή αποθηκευμένης πληροφορίας Τροποποίηση αποθηκευμένης πληροφορίας. Μια γλώσσα χειρισμού δεδομένων είναι μια γλώσσα που επιτρέπει στους χρήστες να έχουν πρόσβαση και να χειρίζονται δεδομένα. Αν και δεν είναι τεχνικά σωστό, η γλώσσα αυτή ονομάζεται επίσης γλώσσα ερωτημάτων (query language), διότι αυτό που κάνει είναι να υποβάλλει στον υπολογιστή ερωτήματα (queries) που ζητούν την ανάκτηση συγκεκριμένης πληροφορίας.

11 2 Μοντέλο Οντοτήτων-Συσχετίσεων Το μοντέλο οντοτήτων-συσχετίσεων (E-R) βασίζεται σε μια αντίληψη του κόσμου ο οποίος αποτελείται από βασικά αντικείμενα, τις οντότητες, και τις συσχετίσεις μεταξύ αυτών των αντικειμένων. 2.1 Οντότητα και Σύνολο Οντοτήτων Μια οντότητα είναι ένα αντικείμενο το οποίο υπάρχει και είναι διακριτό από τα άλλα αντικείμενα. Για παράδειγμα, ο Γεώργιος Γεωργίου με ΑΦΜ είναι μια οντότητα, ξεχωριστή από οποιοδήποτε άλλο πρόσωπο. Το ίδιο ισχύει και για το λογαριασμό με αριθμό 900 στο κατάστημα της Σόλωνος. Ενα σύνολο οντοτήτων είναι ένα σύνολο από οντότητες του ίδιου τύπου. Για παράδειγμα, μπορούμε να ορίσουμε σαν σύνολο οντοτήτων όλα τα άτομα που έχουν λογαριασμό σε μια τράπεζα, ή όλους τους λογαριασμούς μιας τράπεζας. Δεν είναι απαραίτητο τα σύνολα οντοτήτων να είναι ξένα μεταξύ τους. Για παράδειγμα, μπορούμε να ορίσουμε το σύνολο των υπαλλήλων της τράπεζας και το σύνολο των πελατών της τράπεζας. Μια οντότητα που ανήκει στο ένα σύνολο μπορεί να ανήκει και στο άλλο, καθώς ο υπάλληλος της τράπεζας μπορεί να έχει και λογαριασμό στην ίδια τράπεζα. Μια οντότητα αντιπροσωπεύεται από ένα σύνολο χαρακτηριστικών. Πιθανά χαρακτηριστικά του συνόλου οντοτήτων πελάτης είναι όνομα-πελάτη, ΑΦΜ, οδός, πόλη-πελάτη. Πιθανά χαρακτηριστικά του συνόλου οντοτήτων λογαριασμός είναι αριθμός-λογαριασμού και υπόλοιπο. Για κάθε χαρακτηριστικό υπάρχει ένα σύνολο επιτρεπτών τιμών, το πεδίο του χαρακτηριστικού. Για παράδειγμα, το πεδίο του χαρακτηριστικού όνομαπελάτη μπορεί να είναι το σύνολο όλων των σειρών χαρακτήρων κειμένου με κάποιο μέγιστο μήκος (π.χ. 30 χαρακτήρες). Αντίστοιχα, το πεδίο του χαρακτηριστικού αριθμός-λογαριασμού μπορεί να είναι το σύνολο όλων των θετικών ακεραίων. Φυσικά, το πεδίο του κάθε χαρακτηριστικού εξαρτάται από τα δεδομένα του προβλήματος και καθορίζεται με βάση αυτά. Για παράδειγμα, είναι πιθανό να αποφασιστεί ότι η καταλληλότερη μορφή για τον αριθμό λογαριασμού είναι ένα γράμμα και ένας τριψήφιος αριθμός, π.χ. Α908. Στην περίπτωση αυτή, το πεδίο του χαρακτηριστικού είναι το σύνολο όλων των συνδυασμών ενός γράμματος και ενός θετικού ακεραίου. Μια βάση δεδομένων λοιπόν περιλαμβάνει σύνολα οντοτήτων κάθε ένα από τα οποία περιέχει οντότητες του ίδιου τύπου. Ενα τμήμα μιας τραπεζικής βάσης δεδομένων, η οποία αποτελείται από τα σύνολα οντοτήτων πελάτης και λογαριασμός, φαίνεται στο Σχήμα 2.1. Στο Κεφάλαιο αυτό, θα ασχοληθούμε με πέντε σύνολα οντοτήτων. Χρησιμοποιούνται μοναδικά ονόματα χαρακτηριστικών προς αποφυγή σύγχυσης. Πρέπει πάντως να διευκρινιστεί ότι διαφορετικά σύνολα οντοτήτων μπορούν να έχουν ίδια ονόματα χαρακτηριστικών, καθώς αυτά είναι απολύτως διακριτά για τη βάση δεδομένων. Επειδή τα λογισμικά των διαδεδομένων πακέτων χρησιμοποιούν την αγγλική γλώσσα, για τις οντότητες και τα χαρακτηριστικά τους χρησιμοποιούνται αγγλικά ονόματα.

12 Πέτρου Σόλωνος Αθήνα Παύλου Λαναρά Λάρισα Γεωργίου Ηρας Βόλος Χαρόβας Διός Κοζάνη Μπόζης Πανάρα Θεσ/νίκη Μάζης Αλαμάνας Αθήνα Σχήμα 2.1 Σύνολα οντοτήτων Πελάτης και Λογαριασμός Branch (κατάστημα), το σύνολο όλων των καταστημάτων της τράπεζας, με χαρακτηριστικά br-name (όνομα καταστήματος), br-city (πόλη καταστήματος), assets (περιουσία). Customer (Πελάτης), το σύνολο όλων των ατόμων που έχουν κάποιο λογαριασμό στην τράπεζα, με χαρακτηριστικά cust-name (όνομα-πελάτη), AFM (ΑΦΜ), street (οδός), cust-city (πόλη-πελάτη). Employee (Υπάλληλος), το σύνολο όλων των ατόμων που δουλεύουν στην τράπεζα, με χαρακτηριστικά empl-name (όνομα-υπαλλήλου) και phone (αριθ. τηλεφώνου). Account (Λογαριασμός), το σύνολο όλων των λογαριασμών της τράπεζας, με χαρακτηριστικά acc-number (αριθμός λογαριασμού) και balance (υπόλοιπο). Transaction (συναλλαγή), το σύνολο όλων των συναλλαγών που γίνονται σε της τράπεζας, με χαρακτηριστικά trans-number (αριθμός συναλλαγής), date (ημερομηνία) και amount (ποσό). 2.2 Συσχετίσεις και Σύνολα Συσχετίσεων Μια συσχέτιση είναι μια σύνδεση μεταξύ διαφόρων οντοτήτων. Για παράδειγμα, μπορούμε να ορίσουμε μια συσχέτιση που συνδέει τον πελάτη Γεωργίου με τον λογαριασμό 908. Ενα σύνολο συσχετίσεων είναι ένα σύνολο από συσχετίσεις του ίδιου τύπου. Για τα δύο σύνολα οντοτήτων customer και account μπορεί να οριστεί η συσχέτιση CustAcct που συσχετίζει τους πελάτες με τους λογαριασμούς που έχουν. Η σύνδεση μεταξύ των δύο συνόλων φαίνεται στο Σχήμα 2.2. Η σχέση αυτή είναι ένα παράδειγμα δυαδικής σχέσης και είναι τυπική περίπτωση των σχέσεων που συναντώνται στις περισσότερες πραγματικές βάσεις

13 δεδομένων. Είναι ωστόσο δυνατόν να υπάρχουν και σχέσεις μεταξύ περισσοτέρων από δύο οντοτήτων, όπως, για παράδειγμα, μια σχέση που συνδέει τους πελάτες με τους λογαριασμούς και τα καταστήματα. Οι σχέσεις αυτές συνήθως μπορούν να αποσυντεθούν σε περισσότερες δυαδικές σχέσεις και για το λόγο αυτό δεν θα μας απασχολήσουν περισσότερο. Πέτρου Σόλωνος Αθήνα Παύλου Λαναρά Λάρισα Γεωργίου Ηρας Βόλος Χαρόβας Διός Κοζάνη Μπόζης Πανάρα Θεσ/νίκη Μάζης Αλαμάνας Αθήνα Σχήμα 2.2 και account Σύνολο συσχέτισης μεταξύ των συνόλων οντοτήτων Customer Μια σχέση μπορεί επίσης να έχει (πέρα από τα γνωρίσματα των συνόλων οντοτήτων τα οποία συνδέει) περιγραφικά γνωρίσματα τα οποία αφορούν τη σχέση και μόνο. Για παράδειγμα, η σχέση CustAcct θα μπορούσε να έχει το γνώρισμα Date (ημερομηνία), το οποίο δείχνει πότε ο συγκεκριμένος κάτοχος έκανε την τελευταία του συναλλαγή στο συγκεκριμένο λογαριασμό. Αυτά τα γνωρίσματα δεν είναι ποτέ σχετικά μόνο με τη μία από τις δύο οντότητες που συνδέουν και για αυτό ακριβώς το λόγο αφορούν τη σχέση. Επειδή από εδώ και στο εξής θα ασχολούμαστε μόνο με σύνολα οντοτήτων και με σύνολα σχέσεων, για λόγους απλότητας και συντομίας θα αναφερόμαστε σε αυτά με τους όρους οντότητα και σχέση εννοώντας τα αντίστοιχα σύνολα. 2.3 Γνωρίσματα Οι έννοιες της οντότητας και της σχέσης δεν είναι απόλυτα ξεκάθαρες και είναι δυνατόν να τις ορίσουμε σε κάποιο πρόβλημα με αρκετούς διαφορετικόυς τρόπους. Η σημαντικότερη διαφορά είναι στον τρόπο με τον οποίο χειριζόμαστε τα διάφορα γνωρίσματα. Ας εξετάσουμε την οντότητα Employee, η οποία ορίστηκε παραπάνω και έχει τα γνωρίσματα empl-name και phone. Μπορεί κανείς να υποστηρίξει ότι το τηλέφωνο είναι από μόνο του μια οντότητα, αν θεωρηθεί ότι η εταιρεία έχει έναν αριθμό τηλεφώνων, τα οποία βρίσκονται σε συγκεκριμένο χώρο το καθένα και τα οποία κατανέμονται στους

14 υπαλλήλους ανάλογα με τις ανάγκες της. Στην περίπτωση αυτή, πρέπει να ορίσουμε εκ νέου την οντότητα Employee ως εξής: Την οντότητα Employee με μόνο γνώρισμα το empl-name, Την οντότητα phone με γνωρίσματα phone-number και location (θέση), Τη σχέση EmpPhone, που δείχνει τη σύνδεση μεταξύ υπαλλήλων και αριθμών τηλεφώνου. Ποια είναι η διαφορά μεταξύ των δύο ορισμών; Η πρώτη περίπτωση υποδεικνύει ότι ο υπάλληλος έχει ένα συγκεκριμένο αριθμό τηλεφώνου, ενώ στη δεύτερη περίπτωση υπονοείται ότι ο υπάλληλος μπορεί να έχει περισσότερους από έναν (και ίσως κανέναν) αριθμούς τηλεφώνου, ενώ πιθανότατα υπονοείται επίσης ότι ο αριθμός τηλεφώνου αφορά περισσότερο τη θέση στην οποία βρίσκεται το τηλέφωνο και λιγότερο τον συγκεκριμένο υπάλληλο που το χρησιμοποιεί σε κάποια χρονική περίοδο. Αυτό το απλό παράδειγμα δείχνει και την εγγενή δυσκολία που έχει η καλή σχεδίαση μιας βάσης δεδομένων. Η μόνη γενική αρχή που μπορεί να ισχύει κατά τη σχεδίαση μιας βάσης είναι ότι δεν υπάρχει μία, μοναδική σωστή λύση. Οι επιλογές που πρέπει να γίνουν καθορίζονται πάντα από τις συνθήκες και τους περιορισμούς του συγκεκριμένου προβλήματος και αυτές υποδεικνύουν πάντοτε το σωστό δρόμο που πρέπει να ακολουθήσει η σχεδίαση. 2.4 Περιορισμοί απεικόνισης Ενα σχήμα E-R μπορεί να ορίζει συγκεκριμένους περιορισμούς στους οποίους πρέπει να υπακούει η υλοποίηση της βάσης δεδομένων. Ενας σημαντικός περιορισμός είναι η πληθικότητα απεικόνισης, η οποία δείχνει πόσα μέλη μιας οντότητας μπορούν να συνδεθούν με τα μέλη μιας άλλης οντότητας. Για μια δυαδική σχέση R, ανάμεσα στις οντότητες Α και Β υπάρχουν οι ακόλουθες δυνατότητες, οι οποίες είναι όμοιες με τις γνωστές από τα μαθηματικά συναρτήσεις: Ενα-προς-ένα: μια οντότητα του Α συνδέεται με μία το πολύ οντότητα του Β (Σχήμα 2.3). Πολλά-προς-ένα: μια οντότητα του Α συνδέεται με μία το πολύ οντότητα του Β, αλλά μια οντότητα του Β μπορεί να συνδέεται με οσεσδήποτε οντότητες του Α (Σχήμα 2.4). Ενα-προς-πολλά: μια οντότητα του Α μπορεί να συνδέεται με οσεσδήποτε οντότητες του Β, αλλά μια οντότητα του Β μπορεί να συνδέεται με μία μόνο οντότητα του Α (Σχήμα 2.5). Πολλά-προς-πολλά: μια οντότητα του Α μπορεί να συνδέεται με οσεσδήποτε οντότητες του Β και μια οντότητα του Β μπορεί να συνδέεται με οσεσδήποτε οντότητες του Α (Σχήμα 2.6). Είναι προφανές ότι η πληθικότητα απεικόνισης για μια συγκεκριμένη σχέση μεταξύ δύο οντοτήτων καθορίζεται από τη σχέση που υπάρχει μεταξύ των δύο οντοτήτων στον πραγματικό κόσμο. Για μια ακόμη φορά, τονίζεται ότι η κατάστρωση του μοντέλου εξαρτάται αποκλειστικά από τους περιορισμούς

15 που τίθενται στο πραγματικό πρόβλημα και τους οποίους πρέπει πάντοτε να λαμβάνει υπόψη του ο σχεδιαστής. α 1 β 1 α 2 β 2 α 3 β 3 α 4 β 4 Σχήμα 2.3 Σχέση ένα-προς-ένα β 1 α 1 β 2 α 2 β 3 α 3 β 4 β 5 Σχήμα 2.4 Σχέση ένα-προς-πολλά

16 α 1 β 1 α 2 β 2 α 3 α 4 β 3 α 5 Σχήμα 2.5 Σχέση πολλά-προς-ένα β 1 α 1 β 2 α 2 β 3 α 3 β 4 α 4 Σχήμα 2.6 Σχέση πολλά-προς-πολλά Ας εξετάσουμε τη σχέση CustAcct. Αν σε μια τράπεζα ένας λογαριασμός μπορεί να ανήκει μόνο σε έναν πελάτη, αλλά ο πελάτης μπορεί να έχει περισσότερους λογαριασμούς, τότε η σχέση είναι ένα-προς-πολλά από το customer προς το account. Αν όμως ο λογαριασμός μπορεί να ανήκει σε περισσότερους από έναν πελάτες, τότε η σχέση είναι πολλά-προς-πολλά. Στην ακραία υποθετική περίπτωση όπου ο πελάτης δεν μπορεί να έχει πάνω από έναν λογαριασμό στη συγκεκριμένη τράπεζα, η σχέση είναι πολλά-προςένα. 2.5 Κλειδιά Σύνολο οντοτήτων Είναι πολύ σημαντικό να υπάρχει κάποιος τρόπος να διακρίνονται μεταξύ τους οι οντότητες ενός συνόλου. Εννοιολογικά, είναι εύκολη η διάκριση μεταξύ τους και στον πραγματικό κόσμο θεωρείται αυτονόητη, ωστόσο η βάση

17 δεδομένων πρέπει να μπορεί να κάνει αυτή τη διάκριση με βάση τα γνωρίσματα τους. Τέτοιες διακρίσεις μπορούν να γίνουν με βάση την έννοια του υπερκλειδιού (superkey). Υπερκλειδί είναι ένα σύνολο ενός ή περισσοτέρων γνωρισμάτων, τα οποία επιτρέπουν την ταυτοποίηση κάθε οντότητας μέσα στο σύνολο. Με άλλα λόγια, αυτά τα γνωρίσματα δεν έχουν ποτέ τον ίδιο συνδυασμό τιμών για δύο διαφορετικές οντότητες του συνόλου. Για παράδειγμα, το γνώρισμα AFM του συνόλου οντοτήτων customer επαρκεί για τη διάκριση μεταξύ των διαφορετικών οντοτήτων και επομένως είναι ένα υπερκλειδί. Παρομοίως, ο συνδυασμός των γνωρισμάτων AFM και cust-name μπορεί να κάνει αυτή τη διάκριση και συνεπώς αποτελεί ένα δεύτερο υπερκλειδί για το σύνολο customer. Δεν συμβαίνει το ίδιο για το γνώρισμα cust-name, καθώς μπορεί να υπάρχουν δύο οντότητες με το ίδιο όνομα. Η έννοια του υπερκλειδιού δεν είναι επαρκής για τους σκοπούς μας. Οπως φαίνεται και από το παραπάνω παράδειγμα, το υπερκλειδί μπορεί να περιέχει και γνωρίσματα τα οποία είναι περιττά. Αυτό που ενδιαφέρει πραγματικά είναι υπερκλειδιά τα οποία δεν μπορούν να περιοριστούν περισσότερο, δεν περιέχουν δηλαδή περιττές μεταβλητές. Τέτοια κλειδιά ονομάζονται υποψήφια κλειδιά (candidate keys). Είναι δυνατόν να υπάρχουν αρκετοί διαφορετικοί συνδυασμοί που μπορούν να λειτουργήσουν σαν υποψήφια κλειδιά. Αν, για παράδειγμα, σε κάθε οδό μιας πόλης έχουμε μόνο έναν πελάτη, τότε ο συνδυασμός των γνωρισμάτων street και cust-city είναι αρκετός για να διακρίνει τις οντότητες του συνόλου customer και επομένως είναι υποψήφιο κλειδί, όπως βέβαια και το γνώρισμα AFM. Αν και δεν είναι υποχρεωτικό, συνήθως ο σχεδιαστής της βάσης επιλέγει ένα από τα υποψήφια κλειδιά, το οποίο αποτελεί το μέσο ταυτοποίησης των διαφόρων οντοτήτων ενός συνόλου οντοτήτων και το οποίο ονομάζεται πρωτεύον κλειδί (primary key). Είναι ωστόσο δυνατό κάποιο σύνολο οντοτήτων να έχει γνωρίσματα τα οποία δεν επαρκούν για να διακρίνουν μεταξύ τους όλες τις οντότητες. Στην περίπτωση, αυτή δεν υπάρχουν υποψήφια κλειδιά και το σύνολο λέγεται σύνολο ασθενών οντοτήτων (weak entity set). Σε αντίθεση, σύνολο που έχει υποψήφια κλειδιά (άρα και κάποιο πρωτεύον κλειδί, αν το επιθυμούμε) ονομάζεται σύνολο ισχυρών οντοτήτων (strong entity set). Για παράδειγμα, ας εξετάσουμε το σύνολο transaction, με γνωρίσματα trans-number, date και amount. Κάθε οντότητα του transaction είναι διακριτή, ωστόσο είναι δυνατόν συναλλαγές σε διαφορετικούς λογαριασμούς να έχουν τον ίδιο αριθμό συναλλαγής. Για παράδειγμα, είναι πιθανό το σύστημα να καταχωρεί μια μεταφορά χρημάτων από έναν λογαριασμό σε κάποιον άλλο σαν κατάθεση στον ένα λογαριασμό και σαν ανάληψη από τον άλλο. Στην περίπτωση αυτή, έχουμε δύο απόλυτα όμοιες συναλλαγές, οι οποίες πρέπει να είναι μέλη του συνόλου transaction. Αυτό το σύνολο λοιπόν είναι ασθενές και δεν έχει πρωτεύον κλειδί. Για να έχει νόημα η ύπαρξη ενός τέτοιου συνόλου, πρέπει αυτό να είναι τμήμα μιας σχέσης ένα-προς-πολλά. Αν και ένα σύνολο ασθενών οντοτήτων δεν έχει πρωτεύον κλειδί, χρειαζόμαστε να έχουμε κάποιο τρόπο για να διακρίνονται μεταξύ τους οι οντότητες οι οποίες εξαρτώνται από μια συγκεκριμένη ισχυρή οντότητα. Το διακριτικό (discriminator) ενός συνόλου ασθενών οντοτήτων είναι ένα σύνολο

18 γνωρισμάτων που επιτρέπει αυτή τη διάκριση. Στο παράδειγμα μας, το διακριτικό είναι το γνώρισμα trans-number, καθώς για κάθε λογαριασμό ο αριθμός συναλλαγής αφορά μία και μοναδική συναλλαγή. Το πρωτεύον κλειδί ενός συνόλου ασθενών οντοτήτων σχηματίζεται από το πρωτεύον κλειδί του συνόλου ισχυρών οντοτήτων από το οποίο εξαρτάται και το διακριτικό του. Στο παράδειγμα μας, το σύνολο transaction έχει σαν πρωτεύον κλειδί το συνδυασμό acc-number (το οποίο προσδιορίζει το λογαριασμό) και trans-number (το οποίο προσδιορίζει τη συναλλαγή). Σύνολο σχέσης Το πρωτεύον κλειδί ενός συνόλου οντοτήτων μας επιτρέπει τη διάκριση μεταξύ των διαφόρων οντοτήτων του συνόλου. Χρειαζόμαστε έναν παρόμοιο μηχανισμό για τη διάκριση των μελών ενός συνόλου σχέσης. Εστω R ένα σύνολο σχέσης η οποία συνδέει δύο σύνολα Ε 1 και Ε 2, με πρωτεύοντα κλειδιά p 1 και p 2. Τότε τα γνωρίσματα της σχέσης είναι τα p 1 και p 2, καθώς και οποιαδήποτε άλλα γνωρίσματα έχει η ίδια η σχέση. Για παράδειγμα, ας εξετάσουμε τη σχέση CustAcct, την οποία ορίσαμε παραπάνω και η οποία φαίνεται στο Σχήμα 2.7. Τα σύνολα οντοτήτων που εμπλέκονται είναι το Customer με πρωτεύον κλειδί το AFM και το account με πρωτεύον κλειδί το acc-number. Η σχέση έχει επίσης και το γνώρισμα date, το οποίο δείχνει πότε δηλώθηκε ο πελάτης σαν ιδιοκτήτης του λογαριασμού. Η σχέση CustAcct έχει λοιπόν τα γνωρίσματα AFM, acc-number και date. cust-name AFM street cust-city date acc-number balance customer CustAcct Account Σχήμα 2.7 Διάγραμμα E-R Είναι σημαντικό να κατανοηθεί ο παραπάνω μηχανισμός, ο οποίος δείχνει και τη μεγάλη δύναμη που έχει ένα σύστημα βάσης δεδομένων. Στο παράδειγμα που αναφέρθηκε, η απεικόνιση της σχέσης μεταξύ των δύο συνόλων οντοτήτων δεν απαιτεί όλα τα στοιχεία των οντοτήτων τα οποία αποτελούν χαρακτηριστικά, αλλά μόνο τα κλειδιά τους. Αυτό συμβαίνει διότι οποιοδήποτε άλλο στοιχείο αφορά τις οντότητες μπορεί να ανακτηθεί αν γνωρίζουμε την τιμή του πρωτεύοντος κλειδιού. Φυσικά, αν υπάρχουν και γνωρίσματα τα οποία αφορούν αποκλειστικά τη σχέση (όπως η ημερομηνία), τότε λογικά πρέπει να αποτελούν και τμήμα της σχέσης αυτής. Γενικά, η δυνατότητα ανάκτησης που δίνει η ύπαρξη πρωτεύοντος κλειδιού δίνει μεγάλες δυνατότητες στη βάση δεδομένων και για το λόγο αυτό αποτελεί ένα από τα βασικότερα εργαλεία στη σχεδίαση και τη λειτουργία της. Αφού ορίσθηκαν τα γνωρίσματα που περιέχει η σχέση, πρέπει να ορισθεί και το πρωτεύον κλειδί. Η ιδιαιτερότητα εδώ είναι ότι ο ορισμός του κλειδιού σε ένα σύνολο σχέσης εξαρτάται από την πληθικότητα της σχέσης, δηλαδή αν αυτή είναι ένα-προς-πολλά, πολλά-προς-πολλά, κτλ. Αν η σχέση δεν έχει γνωρίσματα που να σχετίζονται με αυτήν (άρα αποτελείται από την ένωση

19 των πρωτευόντων κλειδιών των συνόλων οντοτήτων), τότε το σύνολο των γνωρισμάτων της αποτελεί ένα υπερκλειδί. Αν η σχέση είναι πολλά-προςπολλά (κάθε πελάτης μπορεί να έχει πολλούς λογαριασμούς και κάθε λογαριασμός μπορεί να έχει πολλούς κατόχους), τότε το υπερκλειδί αυτό δεν μπορεί να περιορισθεί άλλο και όλα τα γνωρίσματα αποτελούν και το πρωτεύον κλειδί. Αν η σχέση είναι πολλά-προς-ένα από τους πελάτες προς τους λογαριασμούς (δηλαδή ο πελάτης μπορεί να έχει το πολύ έναν λογαριασμό), τότε το υπερκλειδί μπορεί να περιορισθεί και το πεδίο AFM αποτελεί το πρωτεύον κλειδί. Αυτή είναι μια καλή ευκαιρία για να τονισθεί η πληθώρα των πιθανών λύσεων σε κάποιο πρόβλημα, ανάλογα με τις απαιτήσεις. Αν ισχύει η τελευταία περίπτωση (ο πελάτης μπορεί να έχει το πολύ έναν λογαριασμό), τότε πιθανόν η βέλτιστη σχεδίαση να είναι να περιληφθεί στην οντότητα των πελατών ένα καινούριο γνώρισμα, ο αριθμός λογαριασμού, και να πάψει να υπάρχει η ανάγκη συσχέτισης του συνόλου οντοτήτων customer με το σύνολο οντοτήτων account. Εφόσον ο πελάτης έχει το πολύ έναν λογαριασμό, αυτό ισοδυναμεί με την προσθήκη μιας νέας στήλης στον πίνακα με τα στοιχεία των πελατών, χωρίς περιττές επαναλήψεις. Αν η σχέση έχει γνωρίσματα που να σχετίζονται με αυτήν, τότε τα υπερκλειδιά σχηματίζονται όπως και πριν, με την πιθανή προσθήκη κάποιων από αυτά τα γνωρίσματα. Η προσθήκη αυτή εξαρτάται από τη σημασία που έχουν τα πρόσθετα γνωρίσματα. Για να φανεί αυτό, ας θεωρήσουμε και ένα νέο σύνολο οντοτήτων, το οποίο ονομάζεται banker και περιέχει τους υπαλλήλους της τράπεζας που έχουν κάποια συναλλακτική σχέση με πελάτες, και τη σχέση CustBank, η οποία συνδέει τα σύνολα Banker και Customer. Ας υποθέσουμε ότι αυτή η σχέση έχει και το γνώρισμα type, το οποίο δείχνει το ρόλο που μπορεί να έχει ο υπάλληλος στη σχέση του με έναν πελάτη. Αν αυτός ο ρόλος δεν είναι μοναδικός στη σχέση μεταξύ υπαλλήλου και πελάτη, τότε το πρωτεύον κλειδί αποτελείται από την ένωση των κλειδιών των δύο οντοτήτων με την προσθήκη του γνωρίσματος type. Αν όμως ο συγκεκριμένος υπάλληλος μπορεί να έχει μόνο έναν ρόλο στις σχέσεις του με τους πελάτες, τότε δεν απαιτείται η προσθήκη του γνωρίσματος type στο πρωτεύον κλειδί. 2.6 Διάγραμμα Οντοτήτων-Συσχετίσεων (Entity-Relationship Diagram, Ε-R) Οπως είδαμε παραπάνω, η λογική δομή μιας βάσης δεδομένων μπορεί να παρασταθεί με το διάγραμμα E-R. Αυτό αποτελείται από τις παρακάτω συνιστώσες: Ορθογώνια, τα οποία παριστάνουν σύνολα οντοτήτων, Ελλείψεις, οι οποίες παριστάνουν χαρακτηριστικά, Ρόμβους, οι οποίοι παριστάνουν σχέσεις μεταξύ συνόλων οντοτήτων και Γραμμές, οι οποίες συνδέουν τα χαρακτηριστικά με τα σύνολα οντοτήτων και τα σύνολα οντοτήτων με τις σχέσεις. Στο Σχήμα 2.7, φαίνεται ένα διάγραμμα E-R, το οποίο αποτελείται από δύο σύνολα οντοτήτων, Customer και Account, και τη μεταξύ τους σχέση,

20 CustAcct. Στο σχήμα φαίνονται τα γνωρίσματα τόσο των οντοτήτων όσο και της σχέσης. Στο διάγραμμα μπορεί να φανεί και η πληθικότητα των σχέσεων. Αυτή δείχνεται με ένα βέλος κατεύθυνσης ( ) από τη σχέση προς το σύνολο οντοτήτων το οποίο είναι στην πλευρά «ένα» της σχέσης. Αν, για παράδειγμα, η σχέση CustAcct είναι ένα-προς-πολλά από το customer προς το account, τότε πρέπει να υπάρχει ένα βέλος στην κατεύθυνση του συνόλου customer, και το νέο διάγραμμα φαίνεται στο Σχήμα 2.8 (α). Ανάλογη αλλαγή θα γινόταν αν η σχέση ήταν πολλά-προς-ένα (Σχήμα 2.8 (β)) ή ένα-προς-ένα. Σε ένα τέτοιο διάγραμμα, είναι δυνατόν να απεικονιστούν και ρόλοι. Οι ρόλοι συνήθως υπάρχουν για να εκφράζουν σχέσεις μεταξύ οντοτήτων μέσα στο ίδιο σύνολο οντοτήτων. Στο παράδειγμα μας, είναι πιθανόν να θέλουμε να καταγράψουμε τη σχέση μεταξύ διευθυντών και των υπόλοιπων υπαλλήλων. Επειδή και οι διευθυντές είναι επίσης υπάλληλοι και ανήκουν στο ίδιο σύνολο οντοτήτων, η σχέση αυτή θα απεικονιστεί όπως φαίνεται στο Σχήμα 2.9. cust-name AFM street cust-city date acc-number balance customer CustAcct Account (α) cust-name AFM street cust-city date acc-number balance customer CustAcct Account Σχήμα 2.8 (β) Σχέσεις ένα-προς-πολλά και πολλά-προς-ένα empl-name phone employee διευθυντής υφιστάμενος works Σχήμα 2.9 Διάγραμμα E-R με δείκτες ρόλων

21 Ενα σύνολο ασθενών οντοτήτων φαίνεται στο διάγραμμα σαν ένα ορθογώνιο με διπλό περίγραμμα. Στο Σχήμα 2.10, φαίνεται το σύνολο transaction και η σχέση του με το σύνολο account μέσω της σχέσης log. Οπως αναλύθηκε και νωρίτερα, η σχέση αυτή είναι ένα-προς-πολλά από το account προς το transaction, κάτι που δείχνεται με το σχετικό βέλος κατεύθυνσης. acc-number balance trans-number date amount account log transaction Σχήμα 2.10 Διάγραμμα E-R με ασθενή οντότητα 2.7 Μετατροπή του διαγράμματος E-R σε πίνακες Μια βάση δεδομένων η οποία παριστάνεται από ένα διάγραμμα E-R μπορεί να μετατραπεί σε ένα σύνολο πινάκων. Για κάθε σύνολο οντοτήτων και κάθε σύνολο σχέσεων της βάσης δεδομένων, υπάρχει ένας μοναδικός πίνακας ο οποίος παίρνει το όνομα του αντίστοιχου συνόλου οντοτήτων ή συνόλου σχέσεων. Κάθε πίνακας έχει έναν αριθμό στηλών, οι οποίες έχουν επίσης μοναδικά ονόματα. Θα παρουσιάσουμε αυτές τις ιδέες χρησιμοποιώντας το διάγραμμα E-R του Σχήματος cust-name AFM street cust-city date acc-number balance trans-number date amount customer CustAcct Account log transaction Σχήμα 2.11 Διάγραμμα E-R Παράσταση συνόλου ισχυρών οντοτήτων Αν Ε είναι ένα σύνολο ισχυρών οντοτήτων με περιγραφικά χαρακτηριστικά α 1, α 2,..., α n, αυτό το σύνολο παριστάνεται με έναν πίνακα Ε με n διακριτές στήλες οι οποίες αντιστοιχούν στα χαρακτηριστικά του Ε. Κάθε γραμμή του πίνακα αντιστοιχεί σε μια οντότητα του συνόλου Ε. Ας εξετάσουμε το σύνολο ονοτήτων account του διαγράμματος E-R του σχήματος Αυτό το σύνολο οντοτήτων έχει δύο χαρακτηριστικά: accnumber και balance. Αυτό το σύνολο οντοτήτων παριστάνεται από έναν πίνακα που ονομάζεται account, με δύο στήλες, όπως φαίνεται στο σχήμα Η γραμμή (903, 2100) του πίνακα account σημαίνει ότι ο αριθμός λογαριασμού 903 έχει υπόλοιπο 2100 ευρώ. Η προσθήκη μιας νέας

22 οντότητας στη βάση γίνεται με την εισαγωγή μιας γραμμής στον πίνακα. Οι γραμμές μπορούν επίσης να διαγραφούν ή να τροποποιηθούν (αλλαγή σε κάποια στοιχεία τους). Σχήμα 2.12 Ο πίνακας account acc-number balance Αν D 1 είναι το σύνολο των αριθμών λογαριασμού και D 2 το σύνολο όλων των υπολοίπων, κάθε γραμμή του πίνακα account πρέπει να αποτελείται από μια δυάδα (v 1, v 2 ), όπου v 1 είναι ένας αριθμός λογαριασμού (δηλαδή το v 1 ανήκει στο σύνολο D 1 ) και v 2 είναι ένα υπόλοιπο (δηλαδή το v 2 ανήκει στο σύνολο D 2 ). Γενικά, ο πίνακας account θα περιέχει μόνο ένα υποσύνολο του συνόλου όλων των πιθανών γραμμών. Το σύνολο όλων των πιθανών γραμμών του account ονομάζεται καρτεσιανό γινόμενο των D 1 και D 2, και συμβολίζεται με D 1 Χ D 2. Γενικά, αν έχουμε έναν πίνακα με n στήλες, συμβολίζουμε το καρτεσιανό γινόμενο των D 1, D 2,..., D n με D 1 Χ D 2 Χ...Χ D n-1 Χ D n. Ενα άλλο παράδειγμα που μπορούμε να δώσουμε είναι ο πίνακας Customer, ο οποίος έχει τα χαρακτηριστικά cust-name, AFM, street και cust-city και μια υλοποίηση του φαίνεται στο Σχήμα cust-name AFM street Cust-city Αλισάφης Καρύστου Αθήνα Κώτσας Βενιζέλου Αθήνα Κουκλάκης Μάνης Αθήνα Κανατάκης Μακρυνίτσας Θεσ/νίκη Ανδρέου Βόλου Θεσ/νίκη Μπράνης Κρανώνος Καστοριά Ντάκος Δωδώνης Λάρισα Παππάς Τάτση Αρτα Μπότης Τζουμέρκων Αρτα Σχήμα 2.13: Ο πίνακας Customer Παράσταση συνόλου ασθενών οντοτήτων Εστω ότι Α είναι ένα σύνολο ασθενών οντοτήτων με χαρακτηριστικά α 1, α 2,..., α r, και Β είναι το σύνολο ισχυρών οντοτήτων από το οποίο εξαρτάται το Α. Υποθέτουμε ότι το πρωτεύον κλειδί του Β αποτελείται από τα χαρακτηριστικά

23 b 1, b 2,..., b s. Tο σύνολο A παριστάνεται με έναν πίνακα A με μια στήλη για κάθε χαρακτηριστικό του συνόλου {α 1, α 2,..., α r } {b 1, b 2,..., b s }. Για παράδειγμα, το σύνολο transaction που φαίνεται στο διάγραμμα E-R του σχήματος 2.11 έχει τρία χαρακτηριστικά: trans-number, date και amount. Το πρωτεύον κλειδί του συνόλου account, από το οποίο εξαρτάται το transaction, είναι το acc-number. Το transaction παριστάνεται από έναν πίνακα με τέσσερις στήλες, τις acc-number, trans-number, date και amount, όπως φαίνεται στο σχήμα Παρατηρήστε τη συναλλαγή με αριθμό 451, η οποία προφανώς αφορά μια μεταφορά χρημάτων από έναν λογαριασμό σε άλλον. Αυτή έχει τον ίδιο αριθμό και την ίδια ημερομηνία και στους δύο λογαριασμούς. Η συναλλαγή αυτή τονίζει το γεγονός ότι η συγκεκριμένη οντότητα είναι ασθενής. Acc-number trans-number date amount /8/ /2/ /2/ /2/ /2/ /6/ /8/ /1/ /1/ /3/ Σχήμα 2.14 Ο πίνακας transaction Παράσταση συνόλων συσχετίσεων Εστω ένα σύνολο συσχετίσεων R, το οποίο συσχετίζει τα σύνολα οντοτήτων E 1, E 2,, E m και το οποίο έχει n χαρακτηριστικά. Αυτό το σύνολο παριστάνεται με έναν πίνακα R με n διακριτές στήλες, κάθε μια από τις οποίες αντιστοιχεί σε ένα από τα χαρακτηριστικά. Για παράδειγμα, η σχέση CustAcct στο διάγραμμα E-R του Σχήματος 2.11 συσχετίζει τα σύνολα οντοτήτων customer (πρωτεύον κλειδί AFM) και account (πρωτεύον κλειδί acc-number). Η σχέση έχει και το χαρακτηριστικό date, συνεπώς ο πίνακας CustAcct έχει τρεις στήλες, τις AFM, acc-number και date, όπως φαίνεται στο Σχήμα AFM acc-number Date /9/ /9/ /2/ /5/ /7/ /2/ /1/ /2/ /12/87

24 /12/ /12/ /8/ /5/00 Σχήμα 2.14 Ο πίνακας CustAcct Η περίπτωση των συνόλων συχετίσεων που συνδέουν ένα σύνολο ασθενών οντοτήτων με το αντίστοιχο σύνολο ισχυρών οντοτήτων είναι ειδική. Αυτές οι συσχετίσεις είναι πολλά-προς-ένα και δεν έχουν περιγραφικά χαρακτηριστικά. Επίσης, το πρωτεύον κλειδί ενός συνόλου ασθενών οντοτήτων περιλαμβάνει το πρωτεύον κλειδί του συνόλου ισχυρών οντοτήτων. Στο παράδειγμα του Σχήματος 2.10, το ασθενές σύνολο transaction εξαρτάται από το ισχυρό σύνολο account μέσω του συνόλου συσχετίσεων log. Το πρωτεύον κλειδί του transaction είναι {acc-number, trans-number} και το πρωτεύον κλειδί του account είναι {acc-number}. Η log δεν έχει περιγραφικά χαρακτηριστικά, άρα ο πίνακας για την log θα έχει δύο στήλες, τις acc-number και trans-number. Ο πίνακας για το σύνολο οντοτήτων transaction έχει τέσσερις στήλες, accnumber, trans-number, date και amount. Αρα ο πίνακας log είναι περιττός, κάτι που ισχύει γενικότερα για αυτού του είδους τις σχέσεις. Συνεπώς, δεν χρειάζεται να συμπεριλαμβάνεται στην πινακοειδή παράσταση του διαγράμματος E-R Χρήση Συνόλων Οντοτήτων ή Συνόλων Συσχετίσεων Δεν είναι πάντα ξεκάθαρο αν ένα αντικείμενο περιγράφεται καλύτερα από ένα σύνολο οντοτήτων ή ένα σύνολο συσχετίσεων. Στo Σχήμα 2.15, ο τραπεζικός λογαριασμός μοντελοποιείται σαν οντότητα. Υπάρχει μια σχέση πολλά-προςένα μεταξύ account και branch, η οποία δηλώνει ότι κάθε λογαριασμός είναι χρεωμένος σε ένα κατάστημα. Στο Σχήμα 2.16 παρουσιάζεται ένα εναλλακτικό μοντέλο στο οποίο οι λογαριασμοί παριστάνονται όχι σαν οντότητες αλλά σαν συσχετίσεις μεταξύ πελατών και καταστημάτων, με περιγραφικά χαρακτηριστικά τον αριθμό λογαριασμού και το υπόλοιπο. Στη σχεδίαση αυτή, ένας πελάτης μπορεί να έχει λογαριασμούς σε πολλά καταστήματα και ένα κατάστημα μπορεί να έχει πολλούς πελάτες. Κάθε λογαριασμός παριστάνεται με μια συσχέτιση μεταξύ πελάτη και καταστήματος. cust-name AFM street cust-city acc-number balance br-name br-city assets customer CustAcct Account CustBranch Branch Σχήμα 2.15: Παράσταση της σχέσης μεταξύ καταστημάτων, λογαριασμών και πελατών.

25 cust-name AFM street cust-city br-name br-city assets customer Account Branch acc-number balance Σχήμα 2.16: Παράσταση της σχέσης του Σχ. 2.15, με την account να δείχνεται σαν σχέση και όχι σαν οντότητα. Αν πολλοί πελάτες μπορούν να έχουν έναν κοινό λογαριασμό, η σχεδίαση του Σχήματος δεν είναι κατάλληλη. Πρέπει να ορισθεί μια ξεχωριστή σχέση για κάθε κάτοχο του κοινού λογαριασμού, η οποία πρέπει φυσικά να έχει την ίδια τιμή για τα περιγραφικά χαρακτηριστικά acc-number και balance. Αν όμως κάθε λογαριασμός έχει μόνο έναν κάτοχο, η σχεδίαση του σχήματος είναι ικανοποιητκή.

26 3 Σχεσιακό Μοντέλο Το σχεσιακό μοντέλο είναι σχετικά καινούριο, καθώς τα πρώτα συστήματα βάσεων δεδομένων βασίστηκαν είτε στο δικτυακό μοντέλο είτε στο ιεραρχικό μοντέλο. Και τα δύο αυτά μοντέλα είναι στενότερα δεμένα με την υλοποίηση της βάσης απ ό, τι το σχεσιακό μοντέλο. Η εισαγωγή του σχεσιακού μοντέλου έδωσε το έναυσμα για την ανάπτυξη ενός μεγάλου όγκου θεωρητικής βάσης για αυτό, η οποία με τη σειρά της έδωσε τη δυνατότητα για την ανάπτυξη τεχνικών οι οποίες κάνουν πιο αποτελεσματική τη σχεδίαση της βάσης και την επεξεργασία των απαιτήσεων του χρήστη. Το μοντέλο αυτό έχει πλέον καθιερωθεί σαν το κύριο μοντέλο δεδομένων που χρησιμοποιείται στη σχεδίαση και ανάπτυξη εμπορικών εφαρμογών, ενώ η χρήση του έχει επεκταθεί και σε άλλες επιστημονικές περιοχές. 3.1 Δομή σχεσιακών Βάσεων Δεδομένων Μια σχεσιακή βάση δεδομένων αποτελείται από μια συλλογή πινάκων, κάθε μία από τις οποίες παίρνει ένα μοναδικό όνομα. Κάθε πίνακας έχει δομή αντίστοιχη με αυτήν που παρουσιάσθηκε στο Κεφάλαιο 2, όπου αναλύθηκε η μετατροπή του διαγράμματος E-R σε πίνακες. Μια γραμμή ενός πίνακα εκπροσωπεί μια συσχέτιση ανάμεσα σε ένα σύνολο τιμών. Ενας πίνακας είναι μια συλλογή τέτοιων συσχετίσεων, επομένως υπάρχει αντιστοιχία μεταξύ της έννοιας του πίνακα και της έννοιας της σχέσης, από την οποία παίρνει το όνομα του το σχεσιακό μοντέλο δεδομένων. Θα χρησιμοποιήσουμε στη συνέχεια διάφορες σχέσεις για να διατυπώσουμε τις βασικές αρχές που διέπουν το σχεσιακό μοντέλο δεδομένων. Αυτές οι σχέσεις αποτελούν τμήματα ενός τραπεζικού οργανισμού Βασική Δομή Ο πίνακας deposit του Σχήματος 3.1 έχει τέσσερα χαρακτηριστικά: br-name (όνομα καταστήματος), acc-number (αριθμός λογαριασμού), cust-name (όνομα πελάτη), balance (υπόλοιπο). Για κάθε χαρακτηριστικό, υπάρχει ένα σύνολο επιτρεπομένων τιμών, που ονομάζεται πεδίο τιμών του χαρακτηριστικού. Για το χαρακτηριστικό br-name, για παράδειγμα, το πεδίο τιμών είναι το σύνολο όλων των ονομάτων καταστημάτων. Ονομάζουμε το σύνολο αυτό D 1, το σύνολο των αριθμών λογαριασμού D 2, το σύνολο των ονομάτων πελατών D 3, και το σύνολο των υπολοίπων D 4. Οπως είδαμε στο Κεφάλαιο 2, κάθε γραμμή του deposit πρέπει να αποτελείται από μια τετράδα (v 1, v 2, v 3, v 4 ), όπου v 1 είναι ένα όνομα καταστήματος (δηλαδή ανήκει στο D 1 ) v 2 είναι ένας αριθμός λογαριασμού (δηλαδή ανήκει στο D 2 ), v 3 είναι ένα όνομα πελάτη (δηλαδή ανήκει στο D 3 ) και v 4 είναι ένα υπόλοιπο (δηλαδή ανήκει στο D 4 ). Γενικά, ο deposit θα περιλαμβάνει μόνο ένα υποσύνολο του συνόλου όλων των πιθανών γραμμών. Δηλαδή ο deposit θα είναι υποσύνολο του συνόλου D 1 Χ D 2 Χ D 3 Χ D 4 όπου το σύμβολο Χ δηλώνει το καρτεσιανό γινόμενο μεταξύ δύο συνόλων. Γενικά, ένας πίνακας με n στήλες πρέπει να είναι υποσύνολο του D 1 Χ D 2 Χ... Χ D n-1 Χ D n

27 Σχήμα 3.1: br-name acc-number Cust-name balance Ακαδημία 101 Αλισάφης 1200 Σόλωνος 125 Ναξάκης 1342 Λάρισα 234 Κουκλάκης 536 Ακαδημία 345 Τόκης 777 Αγορά 455 Κώτσας 7230 Αριστοτέλους 560 Αλισάφης 1200 Κέντρο 580 Κουκλάκης 1460 Μητροπόλεως 590 Μπάτης 2450 Σόλωνος 600 Μαρμόρκος 6110 Η σχέση deposit Από εδώ και πέρα θα εισαγάγουμε και τον όρο πλειάδα (tuple) σαν ισοδύναμο της γραμμής. Αυτός είναι μαθηματικός όρος ο οποίος αναφέρεται στα μέλη του καρτεσιανού γινομένου. Σε όλες τις σχέσεις, απαιτούμε τα πεδία τιμών όλων των χαρακτηριστικών να είναι ατομικά. Ενα πεδίο τιμών είναι ατομικό όταν τα στοιχεία του πεδίου θεωρούνται αδιαχώριστες μονάδες. Για παράδειγμα, το σύνολο των ακεραίων είναι ένα ατομικό σύνολο, ενώ το σύνολο των ζευγών δύο ακεραίων είναι μη ατομικό. Η διάκριση μεταξύ των δύο σημαίνει ότι συνήθως θεωρούμε ότι οι ακέραιοι δεν έχουν μικρότερα μέρη, ενώ το ζεύγος δύο ακεραίων έχει τέτοια μέρη και συγκεκριμένα τους δύο ακεραίους που το αποτελούν. Φυσικά, ενδέχεται να υπάρχουν περιπτώσεις όπου ενδιαφερόμαστε για το ίδιο το ζεύγος των ακεραίων, οπότε θεωρούμε ότι το ζεύγος είναι ατομικό Σχήμα Βάσης Δεδομένων Οταν μιλάμε για μια βάση δεδομένων, πρέπει να κάνουμε τη διάκριση μεταξύ του σχήματος βάσης δεδομένων (database scheme) και ενός στιγμιοτύπου βάσης δεδομένων, το οποίο είναι τα δεδομένα της βάσης δεδομένων σε μια δεδομένη χρονική στιγμή. Η έννοια ενός σχήματος μιας σχέσης αντιστοιχεί στην έννοια του ορισμού τύπου που συναντάμε στις γλώσσες προγραμματισμού. Μια μεταβλητή κάποιου τύπου έχει μια συγκεκριμένη τιμή σε μια δεδομένη χρονική στιγμή. Ετσι, μια μεταβλητή σε μια γλώσσα προγραμματισμού αντιστοιχεί στην έννοια του στιγμιοτύπου μιας σχέσης. Στα σχήματα σχέσεων δίνουμε ονόματα, ακριβώς όπως δίνουμε ονόματα σε ορισμούς τύπων στις γλώσσες προγραμματισμού. Για το παράδειγμα του πίνακα deposit, δίνουμε το όνομα deposit-scheme. Ετσι θα έχουμε deposit-scheme = (br-name, acc-number, cust-name, balance) Η σχέση deposit έχει το σχήμα deposit-scheme. Αυτό δηλώνεται γράφοντας deposit (deposit-scheme) Γενικά, ένα σχήμα σχέσης είναι μια λίστα χαρακτηριστικών και τα αντίστοιχα πεδία τιμών. Δεν θα ασχοληθούμε προς το παρόν με τον ακριβή ορισμό του πεδίου τιμών, ωστόσο όταν θέλουμε να ορίσουμε κάποιο πεδίο τιμών, θα χρησιμοποιούμε το συμβολισμό: (br-name: string, acc-number: integer, cust-name: string, balance: integer)