ERD επεξήγηση Στόχος μας είναι η ακεραιότητα των δεδομένων και η οργάνωση. Με χρήση των PKs, FKs και constraints πετυχαίνουμε αυτο ακριβώς.
Γενικές παρατηρήσεις:
- Ta Foreign Keys στο script υλοποιούνται μεσω σχέσεων μεταξύ entities στο ERD, για παράδειγμα το Event.FestivalID είναι ξενο κλειδί και δείχνει στον πίνακα Festival. Αυτο μας εξασφαλίζει οτι ενα Event ανήκει σε ένα έγκυρο Festival.
- Associative entities για σχέσεις many-to-many, όπως πχ μεταξύ Stage και Equipment (ένα Stage μπορει να έχει πολλαπλά equipment και ένα equipment μπορεί να χρησιμοποιηθεί απο πολλές σκηνές), χρησιμοποιούμε έναν ενδιάμεσο πίνακα (StageEquipment εδώ). Αυτός περιέχει τα PKs των δύο πινάκων που συνδέει ως FKs, και το δικό του Primary key ειναι ο συνδυασμός αυτων των FKs. Ετσι διατηρούμε ακεραιότητα. Γενικά έχουμε τα ακόλουθα στατικά Entities:
- RoleType (ρόλοι του προσωπικού)
- ExpLevel (βαθμοί εμπειρίας προσωπικού)
- PerformerType (τύπος Performer, artist ή band δηλαδή)
- PerfSlotType (τύπος Performance, warm-up, headline κλπ)
- PaymentMethod (τύποι πληρωμής, με πιστωτική κάρτα, με IBAN κλπ)
- TicketCategory (είδος εισιτηρίου, VIP κλπ) Υπάρχουν ως λεξικά έτοιμα τα οποία παραμένουν στατικά ανεξαρτήτως Festival, event, τοποθεσίας, ημερομηνίας κλπ. Καταφέρνουμε έτσι συνέπεια δεδομένων, αποφεύγοντας δηλαδή τυπογραφικά, εξοικονομούμε χώρο, γιατι σε κάθε εγγραφή του Assignment θα κρατάει το RoleID αντί για το όνομα του ρόλου συνεχώς. Έχουμε επίσης μια ευκολία στην συντήρηση, σε περίπτωση διόρθωσης αλλάζουμε τα στατικά και αμέσως ενημερώνονται τα σχετικά entities, αντι να χρειαστεί να αλλάξουμε όλες τις εγγραφές μια μια.
Έχουμε και τα Entities τα οποία αφορόυν την γεωγραφία και το Φεστιβάλ:
- Continent
- Country
- City
- Address
- Location
- Festival ( με FestivalID κλπ) Ετσι κατέχουμε μια ιεραρχία των γεωγραφικών οντοτήτων. Για την ακεραιότητα των δεδομένων συνδέουμε τις τοποθεσίες με τις πόλεις, τις χώρες και τις ηπείρους μέσω των IDs τους διότι μπορεί να υπάρχουν πολλές πόλεις με το ίδιο όνομα σε διαφορετικές χώρες,ή ακόμη, στην ίδια χώρα. Τα IDs όντας μοναδικά αποτρέπουν να αντιμετωπίσουμε πρόβλημα σχετικά με αυτό το γεγονός. Επίσης στο ERD φαίνονται δύο μονοπάτια απο το Festival προς το Continent γιατι έχουμε επίσης και μια απευθείας σύνδεση προς το Continent απο το Festival για λόγους απόδοσης (πιο γρήγορες αναζητήσεις φεστιβάλ ανά ήπειρο).
Επίσης υπάρχουν οι οντότητες σχετικά για τις σκηνές και τον εξοπλισμό:
- Stage
- Equipment
- StageEquipment Τo Stage αποθηκεύει πληροφορίες για κάθε σκηνή όπως χωρητικότητα και τοποθεσία (μέσω του FK LocationID). Ο StageEquipment είναι πίνακας συσχέτισης, για την many-to-many μεταξύ Stage και Equipment σχέση. ΜΙα σκηνή μπορεί να έχει πολλά είδη εξοπλισμού, και ένα είδος να χρησιμοποιηθεί σε πολλές σκηνές, έχοντας και το πεδίο Quantity σαν attribute καθορίζοντας την ποσότητα ενός είδους εξοπλισμού που θα χρειαστεί μια σκηνή.
Entities για καλλιτέχνες και είδη μουσικής:
- PerformerType
- Performer
- Artist
- Band
- BandMember
- Genre
- Subgenre
- PerformerGenre
- PerformerSubgenre Χρήση του Performer ώς supertype για τους Artist και Band. Επιτρέπει κοινά χαρακτηριστικά να είναι στον Performer και στους επιμέρους πίνακες. Οι PerformerGenre και PerformerSubgenre, επιτρέπουν τις συσχετίσεις μεταξύ Performers και είδη και υπο-είδη (πολλαπλά).
Επίσης έχουμε τα entities Event και PerformanceSlot, με το Event να ορίζει ενα γεγονός μεσα σε ένα φεστιβάλ, σε μια συγκεκριμένη σκηνή και με μια συγκεκριμένη χρονική διάρκεια. Τα triggers που χρησιμοποιούμε στο script αποτρέπουν overlapping ή άκυρους χρόνους. Και με το PerformanceSlot αναλύουμε ένα Event σε επιμέρους εμφανίσεις καλλιτεχνών ( Performers), το SeqNo χρησιμεύει για τη σειρά εμφάνισης στο Event.
Έχουμε και τις οντότητες για το προσωπικό. Το Personnel είναι ο κατάλογος του προσωπικού, το Assignment είναι πίνακας συσχέτισης συνδέοντας το προσωπικό με τα PerformanceSlot και καθορίζουμε τον ρόλο (RoleID) και το επίπεδο εμπειρίας (ExpID) τους για αυτό το συκγεκριμένο slot.
Οντότητες για επισκέπτες και εισιτήρια όπως Visitor, TicketCategory, PaymentMethod, SellerQueue κ.α. Ο Ticket είναι κεντρικός, έχοντας το TicketEAN ώς PK και ορίζοντας στο script ως Unique key το ζεύγος VisitorID και EventID εξασφαλίζουμε οτι ένας επισκέπτης μπορεί να έχει μονο ενα εισιτήριο ανά event. Οι οντότητες SellerQueue και BuyerQueue διαχειρίζονται την πιθανή μεταπώληση εισιτηρίων, και η οντότητα Rating επιτρέπει στους κατόχους εισιτηρίων να βαθμολογήσουν συγκεκριμένα slots, με το trigger trg_rating στο script να εξασφαλίζει μονο τα ενεργοποιημένα εισιτήρια μπορούν να υποβάλουν βαθμολογία.
Τέλος οντότητες σχετικές με εικόνες, Image, FestivalImage, PerformanceImage και PerformerImage (οι τελευταίες 3 είναι οντότητες συσχέτισης). Ετσι επιτρέπουμε ενα φεστιβάλ να έχει πολλές εικόνες, ομοίως και για Performers και Performance slots. Χρησιμοποιούμε τις associative entities για να μην έχουμε στήλες ImageURL1, ImageURL2 στους σχετικούς πίνακες.