10 - Οντοσυσχετιστική Μοντελοποίηση

Βάσεις Δεδομένων Ι - 10
Οντοσυσχετιστική Μοντελοποίηση
(Entity-Relationship Modeling)
(ή E/R Modeling)
Φώτης Κόκκορας (MSc/PhD)
Τμ. Μηχανικών Πληροφορικής ΤΕ ΤΕΙ Θεσσαλίας

Φ. Κόκκορας / Τμ. Μηχανικών Πληροφορικής ΤΕ - ΤΕΙ Θεσσαλίας - 2 - Βάσεις Δεδομένων Ι
Πώς Υλοποιούμε μια Βάση Δεδομένων;
 Η διαδικασία τυποποίησης και υλοποίησης είναι η ακόλουθη:
 Αρχικά (1) προσδιορίζουμε τις πληροφορίες που πρέπει να αποθηκεύσουμε, ανάλογα και με
τη ζητούμενη λειτουργικότητα. Καταγράφουμε τον τρόπο που συσχετίζονται αυτές οι πληρο-
φορίες καθώς και τυχόν περιορισμούς που ισχύουν (κλειδιά, ακεραιότητα δεδομένων, κτλ).
Το στάδιο είναι χρονοβόρο και σημαντικό. Μια κακή σχεδίαση έχει πολλαπλάσιο κόστος!
 πχ. για να υποστηρίξουμε ένα site κοινωνικής δικτύωσης για μπυραρίες θα θέλαμε κάποια
στοιχεία για τους χρήστες, κάποια άλλα για τις μπυραρίες, τις προτιμήσεις των χρηστών, τη
δυνατότητα να βαθμολογούν τις μπυραρίες το πολύ μία φορά, κτλ.
 Γιατί όμως υπάρχει το Σχέδιο Υψηλού Επιπέδου και δεν πάμε απευθείας στο
Σχεσιακό Πρότυπο με χρήση κάποιου συστήματος σχεδίασης σαν το Workbench;
 Η μόνη έννοια του Σχεσιακού Προτύπου είναι η σχέση/πίνακας. Δεν είναι εύκολο να
περιγραφούν όλα με πίνακες σε αυτό το πρώιμο στάδιο! Χρειάζεται ένα πιο εκφραστικό
σχεδιαστικό πρότυπο. Ένα τέτοιο είναι τα οντοσυσχετιστικά διαγράμματα.
 Τα οντοσυσχετιστικά διαγράμματα τα μετατρέπουμε (2) σε Σχεσιακά Schemata με
μια λίγο-πολύ τυποποιημένη διαδικασία και τέλος, με βάση αυτά φτιάχνουμε την
database (3). Έχετε κάνει το (3) στο εργαστήριο για την myBeersDB – export, κτλ.
Ιδέες
Σχέδιο Υψηλού
Επιπέδου
Σχεσιακό
Schema
Υλοποίηση σε
κάποιο RDBMS
1 2 3

Οντοσυσχετιστικό Πρότυπο
(για ευκολία, στο εξής θα το αποκαλούμε E/R Πρότυπο)
 Περιέχει 3 είδη στοιχείων:
 Οντοσύνολα (entity sets, σύνολα οντοτήτων)
 Γνωρίσματα (attributes)
 Συσχετίσεις (Relationships)
 Με τα παραπάνω στοιχεία φτιάχνουμε τα οντοσυσχετιστικά διαγράμματα
 ή αλλιώς διαγράμματα οντοτήτων-συσχετίσεων ή πιο απλά E/R διαγράμματα
 Τα E/R διαγράμματα θα τα μετατρέψουμε μετά σε Σχεσιακά Schemata

Βασικές Έννοιες
 Οντότητα (entity): πράγμα ή αντικείμενο (πελάτης, μπαρ, μπύρα, εστιατόρια, κτλ)
 Οντοσύνολο (entity set): συλλογή από παρόμοιες οντότητες
 σαν την κλάση (class) στον αντικειμενοστραφή προγραμματισμό – δεν περιέχει όμως και
μεθόδους ή συναρτήσεις όπως στον αντικειμενοστραφή προγραμματισμό!
 αναπαρίσταται με ορθογώνιο
 Γνώρισμα (attribute): Ιδιότητα ενός συνόλου οντοτήτων. Θεωρούμε ότι ένα
γνώρισμα περιέχει πρωταρχικούς τύπους όπως αλφαριθμητικά, ακέραιους, κτλ.
 πχ. τα εστιατόρια έχουν όνομα, διεύθυνση, τηλέφωνο, κτλ
 αναπαρίσταται με οβάλ/έλλειψη
 Συσχετίσεις (relationships): συνδέσεις ανάμεσα σε
δύο ή περισσότερα οντοσύνολα.
 πχ. ένας drinker συχνάζει σε συγκεκριμένο bar
 αναπαρίσταται με ρόμβο
 Τιμή ενός οντοσυνόλου είναι το σύνολο των οντοτήτων που ανήκουν σε αυτό.
 Παράδειγμα: στο οντοσύνολο bars, τιμή είναι τα καταχωρημένα bar
 Τιμή μιας συσχέτισης είναι ένα σύνολο πλειάδων αποτελούμενων από στοιχεία των
συσχετιζόμενων οντοσυνόλων (relationship set – πλειαδοσύνολο συσχέτισης).
 Παράδειγμα πλειάδας της σχέσης Sells: (Blue Angel, Budweiser,6.5).

Παράδειγμα E/R Διαγράμματος
 Κλειδιά: τα γνωρίσματα που αποτελούν κλειδιά επισημαίνονται με υπογράμμιση.
 Αν το κλειδί είναι σύνθετο υπογραμμίζουμε όλα τα μέλη του.
 Προσοχή! Μια συσχέτιση μπορεί να έχει και δικά της γνωρίσματα (βλ. slide #9)
 Παρακάτω θα δούμε:
 επιπλέον λεπτομέρειες των E/R διαγραμμάτων
 πώς μετατρέπουμε το E/R διάγραμμα σε σχεσιακό πρότυπο
name
name
addr
license
manf
name
BeersSells
Likes
Bars
addr
Drinkers
τα bar πωλούν
μπύρες
οι drinkers
συχνάζουν σε
bar
στους drinkers
αρέσουν μπύρες

Πολλαπλές Συσχετίσεις
(Multiway Relationships)
 Συσχετίσεις που συνδέουν πάνω από δύο οντοσύνολα.
 Παράδειγμα: Έστω μια συσχέτιση preferences (προτιμήσεις) που λέει ότι οι
drinkers προτιμούν πάντα να πίνουν συγκεκριμένη μπύρα σε συγκεκριμένο bar.
 Δεν είναι εφικτό να τη μοντελοποιήσουμε με δυαδικές σχέσεις. Απαιτείται τριπλή!
name
name
addr
license
manf
nameaddr
Preferences
BeersBars
Drinkers

Πολλαπλότητα Διμελών Συσχετίσεων (1/2)
 Γενικά, σε μια διμελή συσχέτιση, κάθε οντότητα του ενός οντοσυνόλου μπορεί να
συσχετίζεται με οσαδήποτε μέλη του άλλου οντοσυνόλου. Συχνά όμως θέλουμε
έλεγχο στην πολλαπλότητα μιας συσχέτιση οπότε έχουμε τα εξής:
 Μονοσήμαντες Συσχετίσεις (Πολλά προς Ένα / Many to One)
 Κάθε drinker έχει το πολύ μία αγαπημένη μπύρα
 συμβολίζεται με βέλος προς το Beers
 Μια μονοσήμαντη σχέση είναι πολυσήμαντη προς την αντίθετη κατεύθυνση.
 Κάθε μπύρα μπορεί να είναι η αγαπημένη πολλών drinker.
 Αμφιμονοσήμαντες Συσχετίσεις (Ένα προς Ένα / One to One)
 Κάθε διευθυντής διευθύνει το πολύ μία εταιρία
 συμβολίζεται με το βέλος προς την εταιρία
 Κάθε εταιρία διευθύνεται από το πολύ έναν διευθυντή
 συμβολίζεται με το βέλος προς τον διευθυντή
Favorite BeersDrinkers το πολύ μία
Διευθύνει ΕταιρίαΔιευθυντής
το πολύ μίατο πολύ έναν

Πολλαπλότητα Διμελών Συσχετίσεων (2/2)
 Αμφιπολυσήμαντες Συσχετίσεις (Πολλά προς Πολλά / Many to Many)
 Κάθε μπαρ πουλά πολλές διαφορετικές μπύρες.
 Κάθε μπύρα πωλείται σε πολλά διαφορετικά μπαρ.
 Προσέξτε την απουσία βελών και στις δύο περιπτώσεις.
 Μερικές φορές θέλουμε μια οντότητα από το ένα οντοσύνολο να σχετίζεται με μια
υπαρκτή οντότητα από το άλλο οντοσύνολο (περιορισμός παραπεμπτικής ακεραι-
ότητας - referential integrity constraint).
 Κάθε μπύρα μπορεί να είναι η "best seller" μπύρα σε το πολύ έναν κατασκευαστή.
 συμβολίζεται με το μυτερό βέλος προς τον κατασκευαστή (manf)
 Κάθε κατασκευαστής έχει πάντα ακριβώς μία μπύρα που είναι best seller.
 συμβολίζεται με το στρογγυλεμένο βέλος προς το οντοσύνολο Beers
Sells BeersBars
Best Seller BeersManfs
το πολύ έναν
(0 ή 1)
ακριβώς 1

Γνωρίσματα σε Συσχετίσεις
 Είναι χρήσιμο να μπορούμε να προσάψουμε γνωρίσματα σε Συσχετίσεις.
 Φανταστείτε το ως ακόμη μια στήλη στις πλειάδες του πλειαδοσύνολου της σχέσης.
 Παράδειγμα: Στη συσχέτιση Sells που σχετίζει τα οντοσύνολα Bars και Beers,
προσθέτουμε το γνώρισμα price.
 Θα μπορούσαμε να το κάνουμε και όπως απεικονίζεται παρακάτω, αλλά συνήθως
προτιμούμε τον πάνω τρόπο:
 Το βέλος στην πολλαπλή συσχέτιση
σημαίνει ότι "αν επιλέξουμε μια οντότητα
από τα υπόλοιπα οντοσύνολα (δηλ. τα
Bars και Beers) τότε αυτές σχετίζονται με
μία το πολύ οντότητα (από το Prices)".
price
Sells BeersBars
price
Sells BeersBars
Prices

Ρόλοι (Roles)
 Οι ρόλοι είναι ονόματα που προσάπτουμε σε ακμές μιας σχέσης που χρησιμοποιεί το
ίδιο οντοσύνολο πάνω από μία φορά.
 Ενδεικτικά πλειαδοσύνολα για τις παραπάνω σχέσεις:
Husband Wife Buddy1 Buddy2
Νίκος Ευδοκία Κώστας Νίκος
Ηλίας Κατερίνα Νίκη Αθηνά
Φώτης Ελένη Νίκος Κώστας
... ... Νίκη Ελένη
... ...
 Προσέξτε τις πολλαπλότητες (βέλη στο αριστερό σχήμα).
Married
Drinkers
husband wife
Buddies
Drinkers
1 2

Από Διαγράμματα E/R σε Σχεσιακό Schema (1/11)
Οντοσύνολα
 Η μετατροπή E/R διαγραμμάτων σε Σχεσιακά Schemata είναι σχετικά εύκολη και
γίνεται με τη βοήθεια λίγων βασικών κανόνων και αρκετής προσοχής για αποφυγή
προβλημάτων.
 Τα οντοσύνολα μετατρέπονται σε σχέσεις (πίνακες).
 Τα γνωρίσματα ενός οντοσυνόλου γίνονται γνωρίσματα της σχέσης.
 Το κλειδί παραμένει ως είχε και στο E/R διάγραμμα.
 Παράδειγμα
 Οι συσχετίσεις (relationships) του E/R διαγράμματος δεν μετατρέπονται πάντα σε
σχέσεις (πίνακες). Πρέπει να εξεταστούν επιπλέον παράμετροι!
 Στα επόμενα slides παρουσιάζονται αρκετές τέτοιες περιπτώσεις. Εστιάστε στον τρόπο
σκέψης (που είναι κοινός!) καθώς οι περιπτώσεις είναι πολλές για να τις απομνημονεύσετε!
manfname
Beers
Σχέση/Πίνακας: Beers(Name, manf)

Συσχετίσεις: πολλά-προς-πολλά
 Αν η συσχέτιση (ρόμβος) στο E/R είναι τύπου πολλά-προς-πολλά (many-to-many)
τότε η συσχέτιση μετατρέπεται (στο σχεσιακό μοντέλο) επίσης σε πίνακα με
γνωρίσματα:
 τα γνωρίσματα-κλειδιά από τα συσχετιζόμενα οντοσύνολα
 τα γνωρίσματα της ίδιας της σχέσης (τα οβάλ του ρόμβου στο E/R διάγραμμα)
 το τι θα είναι κλειδί στη νέα σχέση απαιτεί λίγη διερεύνηση
 αν η συσχέτιση δεν έχει δικά της γνωρίσματα τότε όλα τα πεδία ορίζουν το κλειδί
 αν η συσχέτιση έχει και δικά της γνωρίσματα τότε ίσως πρέπει να το δούμε συνολικά
 Παράδειγμα #1: στη συσχέτιση likes στο E/R της myBeersDB, σε κάθε drinker μπο-
ρεί να αρέσουν πολλές μπύρες και μια μπύρα να είναι αρεστή από πολλούς drinkers.
 Πρωτεύον κλειδί στη likes είναι ο συνδυασμός των κλειδιών των δύο οντοσυνόλων.
name addr
Likes Beers
name manf
Drinkers
Σχέσεις/Πίνακες
Likes(drinker, beer)

 Παράδειγμα #2: Η συσχέτιση Sells στην myBeersDB είναι πολλά-προς-πολλά (ένα
bar πουλάει πολλές μπύρες και μια μπύρα πωλείται σε πολλά bar) και επιπλέον έχει
και δικό της γνώρισμα (το price/τιμή).
 Το bar δεν αρκεί για κλειδί καθώς έτσι θα μπορούσαμε να καταχωρήσουμε
μια μόνο μπύρα για κάθε bar. Στην 2η
θα παραβιάζαμε το πρωτεύον κλειδί!
 Το beer δεν αρκεί για κλειδί καθώς έτσι θα μπορούσαμε να καταχωρήσουμε
για κάθε μπύρα, ένα μόνο σημείο πώλησης (bar). Στο 2ο
bar που θα
πουλούσε την ίδια μπύρα θα παραβιάζαμε το πρωτεύον κλειδί!
 Ο συνδυασμός bar και beer είναι πρωτεύον κλειδί.
 Το price δεν μπορεί να είναι μέλος του κλειδιού γιατί θα μπορούσαμε να
έχουμε την ίδια μπύρα να πωλείται στο ίδιο bar σε δύο διαφορετικές τιμές!!!
price
Sells BeersBars
namename
Sells(bar, beer, price)
Κακές επιλογές
πρωτεύοντος
κλειδιού
επιτρέπουν τη
δημιουργία
ανωμαλιών!

 Παράδειγμα #3: Έστω η ακόλουθη μοντελοποίηση σε ένα Λύκειο. Τα 3 οντοσύνολα
κατά τα γνωστά θα δώσουν στο σχεσιακό μοντέλο 3 πίνακες. Τι γίνεται όμως με τη
συσχέτιση Διδασκαλία που μοντελοποιεί ότι "ένας καθηγητής διδάσκει ένα ή
περισσότερα μαθήματα, σε ένα ή περισσότερα τμήματα, σε δεδομένη μέρα και ώρα";
Σημείωση: Στη συνέχεια και για λόγους χώρου, παραβλέπουμε κάποια δευτερεύοντα γνωρίσματα.
 Μια ιδέα: Διδασκαλία(idΜαθήματος, idΚαθηγητή, τάξη, αριθμός, ημέρα, ώρα)
 Πρόβλημα: δεν επιτρέπει να καταχωρήσουμε διδασκαλία του ίδιου μαθήματος, από τον ίδιο
καθηγητή, στο ίδιο τμήμα (τάξη-αριθμός) αλλά σε διαφορετική μέρα/ώρα (σύνηθες σε Λύκειο)
 Άρα, σημειώστε ότι το πρωτεύον κλειδί δεν είναι πάντα προφανές!
ημέρα
ΔιδασκαλίαΤμήμα
ώρα
id
Μάθημα
Καθηγητής επώνυμο
τάξη
αριθμός
ος
id
ώρες

...συνέχεια παραδείγματος #3
 Το να αποτελέσουν όλα τα γνωρίσματα κλειδί της σχέσης επίσης δεν επαρκεί.
 π.χ. τότε θα μπορούσαμε να καταχωρήσουμε διαφορετικούς καθηγητές να κάνουν το ίδιο
μάθημα, την ίδια μέρα/ώρα, στο ίδιο τμήμα! Δείτε πόσο απλό είναι να επαληθευτεί:
 (Φυσική, Κόκκορας, Γ, 1, Δευτέρα, 10:00)
 (Φυσική, Παπαδόπουλος, Γ, 1, Δευτέρα, 10:00)
 Τους περιορισμούς στο πρόβλημά μας τους θέτουν το τμήμα και ο καθηγητής, σε
σχέση με το χρόνο! Πάντα πρέπει να αναλογίζεστε τι ακριβώς επιδιώκετε να κάνετε!
 Δεν μπορεί στο ίδιο τμήμα να γίνεται την ίδια χρονική στιγμή πάνω από μία διδασκαλία!
 Άρα (?): Διδασκαλία(Ημέρα, Ώρα, τάξη, αριθμός, idΜαθήματος, idΚαθηγητή)
 Δεν μπορεί ο ίδιος καθηγητής να συμμετέχει την ίδια στιγμή σε πάνω από μία διδασκαλία!
 Άρα (?): Διδασκαλία(Ημέρα, Ώρα, idΚαθηγητή, τάξη, αριθμός, idΜαθήματος)
 Ας πάρουμε την 1η
εκδοχή (παρόμοια μπορείτε να διερευνήσετε και
τη 2η
) και ας προσπαθήσουμε να βρούμε προβληματικές εγγραφές:
 (Δευτέρα, 10:00, Γ, 1, Φυσική, Κόκκορας)
 (Δευτέρα, 10:00, Γ, 2, Ιστορία, Κόκκορας)
 Δεν παραβιάζεται το κλειδί όμως ο ίδιος καθηγητής βρίσκεται
ταυτόχρονα σε δύο τμήματα!!!

 Θα πρότεινε ίσως κανείς να χειριστούμε αυτό το θέμα σε επίπεδο εφαρμογής, δηλ. να
φτιάξουμε την εφαρμογή που θα χρησιμοποιεί αυτή την ΒΔ, με τρόπο που να μην
αφήνει να βάλουμε τον ίδιο καθηγητή ταυτόχρονα σε δεύτερο τμήμα.
 Η μετάθεση της ευθύνης σε παραπάνω επίπεδο είναι η χειρότερη λύση και θα πρέπει να είναι
η έσχατη! Πάντα θα πρέπει να προσπαθούμε να αντιμετωπίσουμε το πρόβλημα σε επίπεδο
database – είναι το καλύτερο σημείο.
 Στη σχέση: Διδασκαλία(Ημέρα, Ώρα, τάξη, αριθμός, idΜαθήματος, idΚαθηγητή)
θα ψάξουμε για τυχόν συναρτησιακές εξαρτήσεις μεταξύ των γνωρισμάτων. Μια
τέτοια είναι η ακόλουθη:
 Τάξη, Αριθμός, Μάθημα  Καθηγητής
 που βασίζεται στην παραδοχή ότι σε δεδομένο τμήμα (τάξη-αριθμός), συγκεκριμένο μάθημα το
κάνει συγκεκριμένος καθηγητής - π.χ. "Ποιος κάνει Άλγεβρα στο Γ 2;" Θυμηθείτε τα σχολικά
σας χρόνια! Πάντα μπορούσαμε να απαντήσουμε με μοναδικό τρόπο σε τέτοιες ερωτήσεις.
 Για την παραπάνω μη τετριμμένη συναρτησιακή εξάρτηση (ΣΕ), το αριστερό μέρος
ΔΕΝ περιέχει το κλειδί της σχέσης. ΑΡΑ η σχέση δεν είναι σε BCNF.
 Υπενθύμιση: μη τετριμμένη σημαίνει ότι το δεξί μέρος δεν είναι υποσύνολο του αριστερού.
 Θα σπάσουμε τη σχέση στα δύο με λίγο εμπειρικό τρόπο για να κερδίσουμε χρόνο.
Μπορείτε να εφαρμόσετε τον αλγόριθμό κανονικοποίησης BC που είδαμε αναλυτικά
στις διαφάνειες #9.

 Σπάμε της αρχική σχέση σε δύο σχέσεις ως εξής:
 μια σχέση προκύπτει από τα γνωρίσματα της ΣΕ
 Διδασκαλία1(Τάξη, Αριθμός, idΜαθήματος, idΚαθηγητή)
 Προσέξτε το κλειδί. Πρακτικά μοιράζουμε τα μαθήματα των διαφόρων τμημάτων σε καθηγητές.
 η δεύτερη σχέση περιέχει τα υπόλοιπα γνωρίσματα της αρχικής σχέσης
(δηλ. τα Ημέρα, Ώρα) μαζί με το αριστερό μέλος της ΣΕ, δηλαδή:
 Διδασκαλία2(Τάξη, Αριθμός, idΜαθήματος, Ημέρα, Ώρα)
 Προσέξτε το κλειδί. Πρακτικά αυτή η σχέση ορίζει τα χρονικά slots
μαθημάτων για κάθε τμήμα.
 Άρα η Διδασκαλία1 μας λέει ποιος καθηγητής κάνεις ποιο μάθημα σε δεδομένο
τμήμα και η Διδασκαλία2 μας λέει σε ποιες μέρα-ώρα (slot) διδάσκεται κάθε μάθημα
τμήματος.
 Συμπέρασμα:
 Η μετατροπή οντοσυσχετιστικού διαγράμματος (E/R) σε σχεσιακό μοντέλο δεν είναι πάντα
προφανής! Απαιτείται βαθύτερη κατανόηση του προβλήματος και των ιδιαιτεροτήτων του.
 Η βαθύτερη κατανόηση του προβλήματος βοηθά στον εντοπισμό συναρτησιακών
εξαρτήσεων. Αυτές είναι σημαντικές γιατί επιτρέπουν να κάνουμε κανονικοποίηση του
σχεσιακού μοντέλου.
 Πάντα η απουσία κανονικοποίησης είναι πηγή προβλημάτων.

Συσχετίσεις: ένα-προς-ένα (1)
 Θα δούμε ιδιαίτερες περιπτώσεις πάνω σε μια σχέση μεταξύ δύο οντοσυνόλων.
Συχνά κάποιες λεπτομέρειες διαφοροποιούν το τι σχέσεις προκύπτουν στη
μετατροπή του E/R διαγράμματος σε σχεσιακό μοντέλο.
 Η σχέση είναι η διδάσκει και τα οντοσύνολα τα Καθηγητής και Μάθημα
 Ένας καθηγητής πρέπει να διδάσκει ένα και μόνο ένα μάθημα και ένα μάθημα πρέπει
να διδάσκεται από έναν και μόνο έναν καθηγητή.
 προσέξτε τα καμπυλωτά βελάκια: υποχρεωτική ύπαρξη μιας οντότητας
 Επειδή δεν μπορεί να υπάρχει καθηγητής χωρίς μάθημα και αντίστροφα, και επειδή η σχέση
είναι ένα-προς-ένα, μπορούμε να παραλείψουμε πλήρως τον πίνακα που αντιστοιχεί στη
συσχέτιση και να ενώσουμε τους πίνακες των οντοσυνόλων σε έναν:
 καθηγητής(idk, επώνυμο, idm, όνομα)
 το idm (κλειδί μαθήματος) πρακτικά δεν χρειάζεται – χρειάζεται όμως ένα UQ ευρετήριο (στο
idm ή στο όνομα μαθήματος) που θα αποτρέψει το ίδιο μάθημα να το διδάσκει και 2ος
καθηγητής
διδάσκει
idk
ΜάθημαΚαθηγητής
επώνυμο όνομα
idm

 Ένας καθηγητής διδάσκει ως ένα μάθημα και ένα μάθημα πρέπει να διδάσκεται από
έναν και μόνο έναν καθηγητή.
 Προσέξτε τους τύπους βελών!
 Δεν είναι υποχρεωτικό ο καθηγητής να διδάσκει κάποιο μάθημα. Κάθε μάθημα όμως πρέπει
να το διδάσκει ένας και μόνο ένας καθηγητής. Άρα θα υπάρχει μια σχέση (πίνακας) για τους
καθηγητές, ανεξάρτητη των μαθημάτων:
 καθηγητές(idk, επώνυμο)
 Επίσης θα υπάρχει και μια σχέση (πίνακας) για τα μαθήματα, που όμως θα περιέχει αναφορά
(ξένο κλειδί) σε καθηγητή. Στο idk θα χρειαστεί και ευρετήριο UQ ώστε να μην επιτραπεί η
καταχώρηση του ίδιου καθηγητή σε περισσότερα από ένα μαθήματα, καθώς δεν το προβλέπει
το σενάριο που εξετάζουμε. Άρα:
 μαθήματα(idm, όνομα, idk)
 Δεν χρειάζεται πίνακας για τη συσχέτιση!
διδάσκει
idk
idm

 Ένας καθηγητής διδάσκει το πολύ ένα μάθημα και ένα μάθημα διδάσκεται από το
πολύ έναν καθηγητή.
 Σε αυτή την περίπτωση δεν είναι υποχρεωτικό να συσχετιστεί καθηγητής με μάθημα
(μπορούμε δηλ. να καταχωρήσουμε καθηγητή χωρίς να του έχει ανατεθεί μάθημα), ούτε
μάθημα με καθηγητή (μπορούμε δηλ. να καταχωρήσουμε μάθημα χωρίς να πούμε ποιος θα
το κάνει).
 Η παραπάνω ευελιξία όμως έχει κάποιο κόστος: πρέπει να φτιάξουμε 3 πίνακες:
 Μάθημα(idm, όνομα)
 Καθηγητής(idk, επώνυμο)
 Διδασκαλία(idk, idm) όπου για προφανείς λόγους μια από τις δύο στήλες θα οριστεί ως
πρωτεύον κλειδί (έστω το idk εδώ) ενώ στην άλλη θα μπει ευρετήριο UQ καθώς δεν πρέπει να
ανατεθεί το ίδιο μάθημα σε πάνω από έναν καθηγητές!
διδάσκει
idk
idm

Συσχετίσεις: ένα-προς-πολλά (1)
 Ένας καθηγητής μπορεί να διδάσκει κανένα, ένα ή περισσότερα μαθήματα και ένα
μάθημα πρέπει να διδάσκεται από έναν και μόνο έναν καθηγητή.
 Ο καθηγητής μπορεί να δηλωθεί ανεξάρτητα από κάποιο μάθημα.
 Καθηγητές(idk, επώνυμο)
 Αντίθετα το μάθημα πρέπει να συσχετιστεί υποχρεωτικά με κάποιον καθηγητή. Άρα ο
πίνακας μαθημάτων πρέπει να έχει ξένο κλειδί στον πίνακα καθηγητών.
 Μαθήματα(idm, όνομα, idk)
 Δεν χρειάζεται πίνακας για τη συσχέτιση ούτε τυχόν ευρετήρια UQ.
διδάσκει
idk
idm

Συσχετίσεις: ένα-προς-πολλά (2)
 Ένας καθηγητής μπορεί να διδάσκει κανένα, ένα ή περισσότερα μαθήματα και ένα
μάθημα διδάσκεται από έναν το πολύ καθηγητή.
 Ο καθηγητής μπορεί να δηλωθεί ανεξάρτητα από κάποιο μάθημα. Άρα:
 Καθηγητές(idk, επώνυμο)
 Το μάθημα μπορεί να δηλωθεί ανεξάρτητα από κάποιον καθηγητή. Άρα:
 Μαθήματα(idm, όνομα)
 Χρειαζόμαστε και πίνακα για το διδασκαλία:
 Διδασκαλία(idm, idk) προσοχή! το κλειδί πρέπει να μπει στο idm γιατί δεν πρέπει το ίδιο
μάθημα να συσχετιστεί και με 2ο
καθηγητή.
διδάσκει
idk
idm

 Η συσχέτιση Likes είναι πολλά-προς-πολλά άρα: Likes(drinker, beer)
 Η συσχέτιση Favorite είναι σαν του slide #22: Favorite(drinker, beer)
 H Married (1:1) θα δώσει Married(husband, wife) με κλειδί στο ένα από τα δύο και
UQ ευρετήριο στο άλλο καθώς κανείς δεν πρέπει να είναι σε σχέση γάμου 2η
φορά.
 Η Buddies (Ν:Μ) θα δώσει Baddies(drinker1, drinker2) με κλειδί το ζευγάρι
καθώς ο drinker1 μπορεί να έχει πολλούς "κολλητούς", άρα δεν μπορεί να είναι
μόνος του κλειδί.
name addr
Likes Beers
name manf
Married
Favorite
Drinkers
Buddies
1 2
husband
wife
Likes(drinker, beer)
Favorite(drinker, beer)
Married(husband, wife)
Buddies(name1, name2)

 Αν και δεν το αναπτύξαμε στα προηγούμενα, θα αναφέρουμε την εξής περίπτωση:
 Αν υπάρχουν γνωρίσματα τα οποία δεν ισχύουν πάντα σε κάποιο οντοσύνολο
(π.χ. χρώμα/color στις μπύρες), μια συνήθης λύση είναι να ενσωματωθούν και αυτά
στη σχέση που αντιστοιχεί στο οντοσύνολο και όταν δεν έχουν νόημα για κάποιες
εγγραφές να παίρνουν τιμή NULL.
 Παράδειγμα:
name manf color
Budweiser Anheuser-Busch NULL
Guinness Arthur Guinness black
 Η παραπάνω λύση είναι η ενδεδειγμένη, εκτός κι αν υπάρχουν πολλά γνωρίσματα ή/και
εγγραφές που είναι συνήθως NULL, οπότε η ενσωμάτωση όλων σε ένα πίνακα επιβαρύνει
τη σχέση χωρίς ιδιαίτερο όφελος. Σε αυτή την περίπτωση, η ακόλουθη οργάνωση με δύο
πίνακες είναι προτιμότερη:
name manf name color
Budweiser Anheuser-Busch Guinness black
Guinness Arthur Guinness

Καλές Πρακτικές (1/3)
 Να αποφεύγεται η επανάληψη πληροφορίας (redundancy).
 Δεν υπάρχει κανένα κέρδος από το να πούμε το ίδιο πράγμα δύο φορές!
 Σπατάλη χώρου και δημιουργία προϋποθέσεων
για άλλα προβλήματα (σε update, delete, κτλ)
 Παραδείγματα:
 Κακή σχεδίαση (1ο
σχήμα) λόγω επανάληψης
της διεύθυνσης του κατασκευαστή (manf).
 Καλή σχεδίαση στο 2ο
E/R διάγραμμα καθώς
αποφεύγεται η επανάληψη.
Αν δεν μπορείτε να αντιληφθείτε τους λόγους,
σκεφτείτε τις σχέσεις ως πλειαδοσύνολα/πίνακες.
πχ τον πίνακα Beers(name, manf, manfAddr)
 Κακή σχεδίαση (δεξιά) καθώς
επαναλαμβάνει τον κατασκευαστή ως
γνώρισμα του οντοσυνόλου Beers και ως
συσχετιζόμενο οντοσύνολο!
manfAddrname manf
Beers
namename addr
ManfByBeers Manfs
manf
namename addr
ManfByBeers Manfs

 Η νόθευση οντοσυνόλων με γνωρίσματα άλλων οντοτήτων είναι ένδειξη κακής
σχεδίασης – δεν είναι υποχρεωτικά πρόβλημα, απλά σκεφτείτε το 2 φορές!
 Σκεφτείτε το παράδειγμα με τις ταινίες, όπου μαζί με τα στοιχεία της ταινίας αποθηκεύαμε
στην ίδια πλειάδα και τον ηθοποιό. Είναι μεν και ο ηθοποιός στοιχείο της ταινίας, πλην όμως
είναι μια διακριτή οντότητα για την οποία πιθανώς θέλουμε αρκετά στοιχεία, άρα θα έχει το
δικό της οντοσύνολο.
 Πολλές φορές αυτός ο εμπειρικός περισσότερο κανόνας γλυτώνει από πολλά προβλήματα!
 Να μην χρησιμοποιείτε οντοσύνολα εκεί που ένα απλό
γνώρισμα συσχέτισης μπορεί να κάνει τη δουλειά.
 Ένα οντοσύνολο, έχει σαφή λόγο ύπαρξης σε δύο περιπτώσεις:
 περιέχει κάτι περισσότερο από το όνομα μιας οντότητας, δηλ. περιέχει
τουλάχιστον ένα γνώρισμα που δεν είναι κλειδί
 είναι το many/πολλά τμήμα σε μια many-many ή many-one σχέση
ακολουθούν παραδείγματα σε αυτό το θέμα

 Το παράδειγμα δεξιά είναι καλή σχεδίαση:
 Στο Manfs αρμόζει να είναι οντοσύνολο γιατί
εκτός από το κλειδί name, έχει ένα επιπλέον
γνώρισμα, το addr (διεύθυνση).
 Στο Beers αρμόζει να είναι οντοσύνολο (παρό-
λο που περιέχει μόνο το γνώρισμα-κλειδί) γιατί
είναι το many τμήμα στην many-one σχέση ManfBy (Manufactured By/κατασκευάζεται από).
 Δεξιά, δεν είναι κακό που το οντοσύνολο Beers
"νοθεύτηκε" με το γνώρισμα manf που πρακτικά
ανήκει σε άλλη οντότητα.
 Ακόμη κι αν είχαμε το manf σε δικό του οντοσύνολο και το συσχετίζαμε με το Beers, θα
έπρεπε να έχουμε στη σχέση Beers ένα σημείο αναφοράς (foreign key/ξένο κλειδί) σε αυτό.
 Στο παράδειγμα δεξιά, καθώς ο κατασκευα-
στής (manfs) δεν είναι τίποτα περισσότερο
από ένα όνομα και επιπλέον δεν βρίσκεται
στο many τμήμα κάποιας σχέσης, κακώς
αποτελεί ξεχωριστό οντοσύνολο. Θα έπρεπε
να γίνει όπως στο προηγούμενο διάγραμμα.
namename addr
ManfByBeers Manfs
name Beers manf
namename
ManfByBeers Manfs

Ασθενή Οντοσύνολα 1/3
 Μερικές φορές οι οντότητες ενός οντοσυνόλου δεν είναι και τόσο ανεξάρτητες και
χρειάζονται "βοήθεια" για να αυτοπροσδιοστούν.
 Παράδειγμα: Έστω μια παγκόσμια database ποδοσφαιριστών (το οντοσύνολο).
 Το επώνυμο και ο αριθμός δεν αρκούν ούτε από μόνα τους αλλά ούτε και μαζί για να
προσδιορίσουν μοναδικά έναν παίκτη.
 υπάρχουν πολλοί ποδοσφαιριστές με ίδιο επώνυμο
 υπάρχουν πολλοί ποδοσφαιριστές με τον ίδιο αριθμό
 υπάρχουν (σπάνια βέβαια!) και ποδοσφαιριστές με ίδιο επώνυμο και ίδιο αριθμό
 Αν όμως συσχετιστούν τα επώνυμο και αριθμός με την ομάδα στην οποία αυτός αγωνίζεται
(οι ομάδες προφανώς είναι άλλο οντοσύνολο) τότε το πρόβλημα λύνεται.
 Σε E/R διάγραμμα αυτό κωδικοποιείται ως εξής:
 Λέμε ότι η συσχέτιση "παίζει_σε" στηρίζει το ασθενές οντοσύνολο "ποδοσφαιριστές".
αριθμός ΟμάδεςΠοδοσφ/στές
επώνυμο
όνομα
id
παίζει_σε
Πρέπει να είναι ΕΝΑ, γιατί κάθε ποδοσφαιριστής χρειάζεται
το κλειδί της ομάδας για να ορίσει το δικό του κλειδί!

 Ένα οντοσύνολο λέγεται ασθενές (weak entity set) όταν για να προσδιοριστεί
μοναδικά μια οντότητά του πρέπει να ακολουθήσουμε μια (ή περισσότερες) πολλά-
προς-ένα συσχετίσεις και να χρησιμοποιήσουμε το κλειδί των συνδεδεμένων
οντοσυνόλων.
 Δεν είναι απαραίτητο όλες οι συσχετίσεις ενός ασθενούς οντοσυνόλου να "στηρίζουν" το
οντοσύνολο!
 Όσες όμως το στηρίζουν, πρέπει να είναι συσχετίσεις -προς-ένα ώστε να εξασφαλίζεται
ύπαρξη οντότητας που θα στηρίξει την ασθενή οντότητα.
 Σε E/R διάγραμμα, η απεικόνιση γίνεται με τα διπλά περιγράμματα στο ασθενές
οντοσύνολο και στις υποστηρίζουσες συσχετίσεις (βλ. προηγούμενο slide).
 Κατά την μετατροπή σε σχεσιακό μοντέλο ισχύουν τα της περίπτωσης ένα-προς-
πολλά. Στο παράδειγμα, οι προκύπτουσες σχέσεις (πίνακες) θα είναι:
 Ομάδες(id, όνομα)
 Ποδοσφαιριστές(αριθμός, επώνυμο, id_ομάδας)
 Η συσχέτιση (ρόμβος) δεν θα δώσει πίνακα (εκτός αν είχε δικά της γνωρίσματα)
 Σκεφτείτε να θέλουμε την ημερομηνία απόκτησης και το ποσό του συμβολαίου του παίκτη!
 Καλή Πρακτική: αποφεύγουμε τα ασθενή οντοσύνολα αν η δουλειά μπορεί να γίνει
με επιπλέον γνώρισμα. Συνήθως αυτό γίνεται με χρήση τεχνητού κλειδιού!

 Παράδειγμα 2
 Ένας user συνδέεται καμία, μία ή περισσότερες φορές σε ένα σύστημα.
 Μια σύνδεση αφορά σε έναν και μόνο έναν user.
 Μετατροπή σε σχεσιακό μοντέλο:
 users(id, όνομα)
 logins(when, ip, id_user)
 Δεν είναι υποχρεωτικό να συμπεριληφθεί η IP address στα γνωρίσματα του οντοσυνόλου
logins. Σε τέτοια περίπτωση η μετατροπή σε σχεσιακό θα έδινε:
 users(id, όνομα)
 logins(when, id_user)
 Κάποιος μπορεί να ισχυριστεί ότι με τον παραπάνω τρόπο, ένας χρήστης μπορεί να κάνει και
δεύτερο login (π.χ. από 2o
PC)! Ο αντίλογος είναι ότι αυτός ο πίνακας απλά καταγράφει το
ιστορικό των logins που γίνονται, δεν δείχνει ποιοι χρήστες είναι συνδεδεμένοι σε δεδομένη
χρονική στιγμή! Αν υπάρχει τέτοιο ζητούμενο τότε θα χρειαστεί επιπλέον πίνακας.
when userslogins
όνομα
id
logged_in
ip

Συμπεράσματα
ΕΞΑΣΚΗΘΕΙΤΕ!
Πρέπει να έχετε γνώση του τι θέλετε να κάνετε με τη ΒΔ!
Συνήθως υπάρχουν πολλές λύσεις. Κάποια όμως είναι καλύτερη για δεδομένη
ανάγκη. Πρέπει να είναι ξεκάθαρο το τι θέλετε να φτιάξετε, πρέπει να έχετε
καταλάβει το πρόβλημα. Μην κρίνετε τα πράγματα με βάση τη δική σας
πραγματικότητα αλλά με αυτή του προβλήματος.
(δείτε πόσες εκδοχές της συσχέτισης "διδασκαλία" αναφέραμε!!)
Στη σχεδίαση ΒΔ ο "λογαριασμός" έρχεται στο τέλος, όταν πάνω στην database
πάμε να χτίσουμε μια εφαρμογή! Με καλή σχεδίαση προχωράνε όλα "ρολόι"!
Με κακή σχεδίαση, αργά ή γρήγορα, θα το πληρώσετε ακριβά
σε χρόνο και προσπάθεια (αν τελικά το ολοκληρώσετε)!
Υπάρχουν προφανώς κι άλλες πιο ειδικές περιπτώσεις (π.χ. δεν αναφέραμε τις
ιεραρχίες οντοτήτων) που λόγο χρόνου δεν μπορούμε να δούμε αναλυτικά.
Παραπέμπεστε για αυτά στη σχετική βιβλιογραφία.
Τέλος, επιδιώξτε να χτίσετε εφαρμογή πάνω στην database σας!
Θα σας κάνει πολύ σοφότερους!

10 - Οντοσυσχετιστική Μοντελοποίηση

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Recently uploaded

Recently uploaded (20)

10 - Οντοσυσχετιστική Μοντελοποίηση