cyanic-selkie/wikianc huggingface dataset:
Ντουμπνά
Πολιτισμός
thumb|Το άγαλμα του Λένιν στα όρια της πόλεως Στη συμβολή του Βόλγα με το Κανάλι της Μόσχας βρίσκεται από το 1937 ένα από τα μεγαλύτερα παγκοσμίως αγάλματα του Βλαντίμιρ Λένιν, με ύψος 25 μέτρα. Αρχικώς συνοδευόταν από άγαλμα του Ιωσήφ Στάλιν παρόμοιου μεγέθους, το οποίο όμως κατεδαφίστηκε ήδη από το 1961, κατά την περίοδο της αποσταλινοποίησης.
Αθλητισμός
Οι αθλητικές εγκαταστάσεις στην πόλη περιλαμβάνουν δύο στάδια, εγκατάσταση για θαλάσσιο σκι στον Βόλγα, τρεις κολυμβητικές δεξαμενές, γήπεδα τένις και 5 αθλητικά συγκροτήματα. Δημοφιλή αθλήματα στην Ντουμπνά είναι η ιστιοσανίδα, το σκι με αετό και το θαλάσσιο σκι στον Βόλγα. Από το 2004 διεξάγεται αγώνας για το Παγκόσμιο Κύπελλο Θαλάσσιου Σκι.
«Αδελφές» πόλεις
Η Ντουμπνά είναι «αδελφοποιημένη» με τις εξής 4 πόλεις :
Εξωτερικοί σύνδεσμοι
Κατηγορία:Όμπλαστ της Μόσχας Κατηγορία:Ευρωπαϊκές πόλεις της Ρωσίας
Αστική Περιοχή Καχάμα
Η Αστική Περιοχή Καχάμα (Αγγλικά: Kahama Urban District, Σουαχίλι: Wilaya ya Kahama), είναι μία από τις πέντε επαρχίες στην Περιφέρεια Σινυάνγκα (Shinyanga Region) της Τανζανίας. Συνορεύει στα βόρεια και νότια με την Αγροτική Περιοχή Καχάμα (Kahama Rural District), ανατολικά με την Περιοχή Νζέγκα (Nzega District) και δυτικά με την Περιοχή Μπουκόμπε (Bukombe District).
Κατά το 2012, σύμφωνα με την Εθνική Απογραφή της Τανζανίας, ο πληθυσμός στην Αστική Επαρχία Καχάμα (Kahama Urban District), ήταν 242.208 άτομα.
Οικονομία
Τώρα, η Καχάμα (Kahama) έχει δηλωθεί και γίνει γνωστή στο κοινό ως αστική περιοχή. Οι πρόσφατες εξελίξεις της, οι οποίες είναι επίσης συναρπαστικές, είναι το αποτέλεσμα του σταθμού μεταφόρτωσης της Ισάκα (Isaka) και οι μεταλλευτικές δραστηριότητες που έχουν αρχίσει εδώ και αρκετό καιρό τώρα. Η πόλη Καχάμα (Kahama), τώρα απολαμβάνει τις εργασίες από την Barrick Gold στην προσφάτως ανοιχθείσα τοποθεσία του Χρυσωρυχείου Μπουζουάγκι (Buzwagi Gold Mine) που βρίσκεται κατά μήκος του δρόμου στην Ισάκα (Isaka), μεταξύ της Καχάμα (Kahama) και της Μουεντακουλίμα (Mwendakulima).
Επίσης, η κατασκευή δραστηριοτήτων είναι τώρα μέρος της πόλης που είναι ήδη συνδεδεμένη στο νέο έργο υδροδότησης από τη Λίμνη Βικτώρια (Lake Victoria), το οποίο ήταν ένα από τα προβλήματα που αντιμετώπιζαν για δεκαετίες, οι κάτοικοι της Καχάμα (Kahama). Έχει πλέον εξελιχθεί στο βαθμό που συνδέεται με το Nyihogo, Malunga, Shunü, Nyahanga, Igomero Nyakato, Mbulu, Bukondamoyo και Mhungulamwime, η οποία επίσης αύξησε την αστική περιοχή.
Μεταφορές
Ο ασφαλτοστρωμένος οδικός Κορμός T3 από το Μορογκόρο προς τα σύνορα της Ρουάντα, περνά μέσα από την Αστική Περιοχή Καχάμα (Kahama Urban District), από τα ανατολικά προς τα δυτικά.
Τμήματα
Από το 2012, η Αστική Περιοχή Καχάμα (Kahama Urban District), διαιρείται διοικητικά σε 20 Τμήματα (σε παρένθεση, ο πληθυσμός εκάστου Τμήματος - κατά το 2012):
• 4
Σημειώσεις
<references responsive="0" group="Σημ." /> <references group="Παρ. Σημ." />
Παραπομπές
Κατηγορία:Επαρχίες της Τανζανίας Κατηγορία:Επαρχίες της Περιφέρειας Σινυάνγκα
Μερόπη Καλανταρίδου
Η Μερόπη Καλανταρίδου είναι Ελληνίδα πετοσφαιρίστρια, η οποία γεννήθηκε στην Θεσσαλονίκη στις 10 Φεβρουαρίου 1990 και αγωνίζεται ως διαγώνια στην ομάδα του Άρη.
Καριέρα
Η Καλανταρίδου ξεκίνησε την καριέρα της από τα τμήματα κορασίδων του Αρχέλαου Κατερίνης και μεταγράφηκε στον Άρη σε ηλικία 15 ετών. Με την ομάδα της Θεσσαλονίκης αγωνίστηκε στην Α1 εθνική κατηγορία μέχρι το 2010, όταν ο Άρης υποβιβάστηκε για πρώτη φορά μετά το 1993.
Μετά από πέντε συνεχόμενες σεζόν στην Α2 εθνική κατηγορία, η ομάδα του Άρη επέστρεψε στην υψηλότερη κατηγορία του ελληνικού πρωταθλήματος το 2015, με την Καλανταρίδου να είναι η παλαιότερη αθλήτρια του συλλόγου.
Πηγές
Κατηγορία:Ελληνίδες αθλήτριες της πετοσφαίρισης Κατηγορία:πετοσφαιρίστριες Άρη
Σαν Χουάν Ζαμπλοτέχ
Η Σαν Χουάν Ζαμπλοτέχ ήταν μια ποδοσφαιρική ομάδα από το Τρινιντάντ και Τομπάγκο, η οποία αγωνιζόταν στην TT Pro League, την ανώτατη κατηγορία της χώρας. Έδρα της ομάδας ήταν το Hasely Crawford Stadium στο Πορτ-οφ-Σπέιν, Τρινιντάντ (νησί). Τη Δευτέρα 2 Ιουλίου 2012, η ομάδα επίσημα παραιτήθηκε από την TT Pro League αφού δεν μπορούσε να πληρώσει τους μισθούς των ποδοσφαιριστών της. Πλέον, διαθέτει μόνο ακαδημίες νέων, έχοντας επισήμως αποσυρθεί από τα πρωταθλήματα της χώρας. Η ομάδα είχε ιδρυθεί το 1974.
Τίτλοι
Εγχώριοι
Διεθνή
Εξωτερικοί σύνδεσμοι
Κατηγορία:Ιδρύσεις ποδοσφαιρικών ομάδων το 1974 Κατηγορία:Ποδοσφαιρικές ομάδες Τρινιντάντ και Τομπάγκο Κατηγορία:Σαν Χουάν Ζαμπλοτέχ
Αντίρροια
Με τον όρο αντίρροια (αντίθετη ροή), ως ουσιαστικό, χαρακτηρίζεται το φυσικό φαινόμενο της παρουσίας ή δημιουργίας, απ' οποιαδήποτε αιτία, θαλάσσιου ρεύματος αντίθετα του συνήθως υφιστάμενου παράκτιου.
Στο φαινόμενο της παλίρροιας ο όρος «αντίρροια» χαρακτηρίζει την μεταστροφή που σημειώνεται ως προς την κατεύθυνση του θαλάσσιου ρεύματος που υπήρχε προηγουμένως σε ορισμένη χρονική στιγμή.
Επίσης ως επίθετο απαντάται στον πληθυντικό ως: αντιρροιακά ρεύματα που πρόκειται κυρίως για ζεύγη θαλασσίων ρευμάτων κινουμένων κατ΄ αντίθετη κατεύθυνση μεταξύ τους, το ένα ύπερθεν του άλλου. Τέτοια «αντιρροιακά ρεύματα» παρατηρούνται στις ακτές του Ανατολικού Αιγαίου και ιδιαίτερα έντονα στα Στενά των Δαρδανελίων μέχρι την έξοδο του Βοσπόρου στη Μαύρη θάλασσα. Το φαινόμενο αυτό δημιουργείται είτε εκ της διαφοράς περιεκτικότητας άλατος, (ως συνηθέστερα), είτε εκ της διαφοράς θερμοκρασίας υποβρύχιου και επιφανειακού ρεύματος. Για παράδειγμα: οι λουόμενοι στις ανατολικές ακτές της Σάμου, εξερχόμενοι από την θάλασσα δεν μένει σχεδόν καθόλου επάνω τους αλάτι, σε αντίθεση με τους λουόμενους στις δυτικές ακτές της Σάμου.
Και οι δύο παραπάνω όροι ως ουσιαστικό και ως επίθετο λαμβάνονται ιδιαίτερα υπ΄ όψη τόσο στη Ναυτιλία, κατά τον επιχειρούμενο από πλοία διάπλου περιοχής που υφίσταται τέτοιο φαινόμενο, όσο και στην διενέργεια αλιείας πλησίον ομοίως  τέτοιων περιοχών, καθώς και σε άλλες υποβρύχιες δραστηριότητες.
Κατηγορία:Θαλάσσια ρεύματα
Αντικειμενοστρεφείς βάσεις δεδομένων
Οι αντικειμενοστρεφείς βάσεις δεδομένων είναι συστήματα βάσεων δεδομένων που κρατούν τα δεδομένα τους σαν αντικείμενα, κατά τις αρχές του αντικειμενοστρεφούς προγραμματισμού.
Βάσεις δεδομένων και αντικειμενοστρεφής προγραμματισμός
Γύρω στα 1986, η προσπάθεια συσχετισμού αντικειμένων και βάσεων δεδομένων, ήταν συναρπαστική. Από την πλευρά των βάσεων δεδομένων υπήρχε η τάση επέκτασης του σχεσιακού μοντέλου, που μόλις πριν από λίγο καιρό είχε καθιερωθεί. Από την πλευρά των γλωσσών προγραμματισμού υπήρχε η τάση πρόσθεσης χαρακτηριστικών όπως διάρκεια στα δεδομένα. Από τη συνάντηση των δύο τάσεων προέκυψε μια ποικιλία απόψεων: κάποιοι πίστευαν ότι ο συνδυασμός χαρακτηριστικών από τις αντικειμενοστρεφείς γλώσσες προγραμματισμού και τις βάσεις δεδομένων θα δημιουργούσε ένα νέο είδος συστημάτων βάσεων δεδομένων. Την ίδια στιγμή, κάποιοι άλλοι πίστευαν ότι, με τη βοήθεια των αντικειμένων, ο κόσμος θα έπρεπε να προσανατολιστεί σε εργαλεία (toolkits) που θα βοηθούσαν τους προγραμματιστές να κατασκευάσουν εξειδικευμένα συστήματα διαχείρισης βάσεων δεδομένων. Στη συνέχεια του κεφαλαίου αυτού, θα παρουσιάσουμε το πώς οι διαφορετικές αυτές προσεγγίσεις κατέληξαν στη δημιουργία των αντικειμενοστρεφών συστημάτων βάσεων δεδομένων. Προηγουμένως, όμως,θα κάνουμε μια μικρή εισαγωγή στις έννοιες του προσανατολισμού στα αντικείμενα. Προσανατολισμός στ' Αντικείμενα (Object Orientation) σημαίνει μια "μοντελοποίηση του λογισμικού και κάποιες αρχές ανάπτυξης που διευκολύνουν την κατασκευή σύνθετων συστημάτων από ξεχωριστά συστατικά" [Kh93]. Τι είναι "Αντικείμενο" (Object); "Αντικείμενο είναι μια ξεχωριστή οντότητα, που προσπαθεί να μοντελοποιήσει και να προσεγγίσει όσον το δυνατό καλύτερα, το φυσικό κόσμο." [CK86]. Ένα αντικείμενο μπορεί να διενεργήσει ένα σύνολο δραστηριοτήτων. Το σύνολο, αυτό, των δραστηριοτήτων του, καθορίζει και τη συμπεριφορά του (object's behaviour). Ο ορισμός της συμπεριφοράς ενός αντικειμένου αποτελείται από τρία μέρη:
Η διαπροσωπεία ενός αντικειμένου αποτελείται από ένα σύνολο εντολών που κάθε μία επιτελεί μία συγκεκριμένη εργασία. Ένα αντικείμενο ζητά από ένα άλλο να εκτελέσει μία εντολή στέλνοντάς του ένα μήνυμα. Ο έλεγχος μεταβιβάζεται από το αντικείμενο αποστολέα (sender) στο αντικείμενο παραλήπτη (receiver), μέχρι το δεύτερο να ολοκληρώσει την ζητηθείσα εντολή. Στη συνέχεια, ο έλεγχος επιστρέφει στον αποστολέα. Ένα μήνυμα μπορεί να περιέχει πληροφορία για τον αποστολέα, με τη μορφή ορισμάτων. Το αντικείμενο παραλήπτης, από την πλευρά του, μπορεί να επιστρέψει μια τιμή πίσω στο αιτούν αντικείμενο. Κάθε μήνυμα λαμβάνει ένα όνομα το οποίο ονομάζεται επιλογέας (selector), και είναι το όνομα αυτό που αποστέλλεται στο αντικείμενο παραλήπτη.
Ένα άλλο σύνηθες φαινόμενο είναι το αντικείμενο που λαμβάνει ένα μήνυμα να στέλνει με τη σειρά του ένα άλλο μήνυμα σε ένα τρίτο αντικείμενο κ.ο.κ..
Ένα από τα χαρακτηριστικά του αντικειμενοστρεφούς προγραμματισμού είναι και το γεγονός, ότι ένα αντικείμενο μπορεί να έρθει σε επικοινωνία με ένα άλλο, μόνο μέσω του interface του δεύτερου. Η λογική και τα δεδομένα κάθε αντικειμένου αποκρύπτονται. Το interface ενθυλακώνει τον κώδικα και τα δεδομένα κάθε αντικειμένου, γι' αυτό και το χαρακτηριστικό αυτό, του αντικειμενοστρεφούς προγραμματισμού, ονομάζεται ενθυλάκωση (encapsulation)
Είναι χαρακτηριστικό φαινόμενο, το γεγονός ότι πολλά αντικείμενα επιδεικνύουν την ίδια ακριβώς συμπεριφορά και διαφέρουν μόνο στην τιμή των μεταβλητών στιγμιοτύπου. Για να μην επαναλαμβάνουμε τη συγγραφή του κώδικα για τις μεθόδους, τα δεδομένα και το interface, φροντίζουμε να ομαδοποιήσουμε τα αντικείμενα σε κλάσεις. Κλάση είναι μια ομάδα από αντικείμενα με παρόμοια σημασιολογία και, εν γένει, παρόμοια δομή και λειτουργίες. Είναι χαρακτηριστικό, ότι στον αντικειμενοστρεφή προγραμματισμό, δεν ορίζουμε αντικείμενα,αλλά τις κλάσεις στις οποίες ανήκουν. Ένα στιγμιότυπο (instance) είναι ένα αντικείμενο που ανήκει στην κλάση αυτή, και έχει τα δικά του δεδομένα. Δομούμε τις κλάσεις σε ιεραρχίες κλάσεων, έτσι ώστε να κατασκευαστεί ένα δέντρο από κλάσεις. Κάθε κλάση κληρονομεί από την πατρική της όλα τα χαρακτηριστικά της δεύτερης,στα οποία, αν υπάρχει ανάγκη, προσθέτει και τα ιδιαίτερα δικά της. Το φαινόμενο αυτό ονομάζεται κληρονομικότητα. Με τον τρόπο αυτό, μπορούμε να ομαδοποιούμε αλλά και να εξειδικεύουμε τα αντικείμενα με μια δενδρική δομή εύκολα αντιληπτή σημασιολογικά, η οποία ταυτοχρόνως μας επιτρέπει να εξοικονομούμε σημαντικό τμήμα κώδικα (αφού δε χρειάζεται να ορίσουμε ξανά τις λειτουργίες και τη δομή μιας θυγατρικής κλάσης -αρκεί να έχει περιγραφεί ο πατέρας της).
Τέλος, άλλο ένα χαρακτηριστικό του αντικειμενοστρεφούς προγραμματισμού είναι το γεγονός ότι διαφορετικά αντικείμενα αντιδρούν με διαφορετικό τρόπο στο ίδιο μήνυμα. (Έχουν, δηλαδή, διαφορετική υλοποίηση της μεθόδου για το ίδιο μήνυμα). Το φαινόμενο ονομάζεται πολυμορφισμός (polymorphism). Τα βασικά χαρακτηριστικά του αντικειμενοστρεφή προγραμματισμού, είναι:
Βασικές αρχές ενός αντικειμενοστρεφούς μοντέλου δεδομένων
Σύμφωνα με το [Mai89] η έννοια μοντέλο δεδομένων (data model) έχει διττή σημασία: σημαίνει αφενός ένα συγκεκριμένο σχήμα ή γενικά, περιγραφή των μεταδεδομένων (metadata) σε μια εφαρμογή, και αφετέρου σημαίνει τον τρόπο με τον οποίο σχήματα ή περιγραφές δεδομένων εκφράζονται σε ένα σύστημα. Για τη δεύτερη ερμηνεία, προς την οποία και εμείς θα προσανατολιστούμε στη συνέχεια, υπάρχουν επίσης, διάφορες παραλλαγές -εμείς θα υιοθετήσουμε τον ορισμό που δίνεται στο [Di93]:
"Ένα μοντέλο δεδομένων είναι ένα σύνολο από λογικά εργαλεία για την περιγραφή της αναπαράστασης της πληροφορίας σε δεδομένα. Περιλαμβάνει δε, ζητήματα σχετικά με:
Η ενότητα αυτή αφορά ζητήματα του αντικειμενοστρεφούς μοντέλου δεδομένων. Κυρίως θα βασιστούμε στο μοντέλο που προτείνεται στο [Di93], το οποίο με τη σειρά του βασίζεται στο μοντέλο που διαφαίνεται να υπάρχει στο [At+89]. Επιπλέον,όπου κρίνεται αναγκαίο, θα αναφέρουμε τις ενστάσεις και τους προβληματισμούς άλλων επιστημόνων.
Η γενική ιδέα είναι ότι ένα αντικειμενοστρεφές μοντέλο δεδομένων προσπαθεί να ενώσει ιδέες που διέπουν αντικειμενοστρεφή συστήματα, με καθιερωμένες ιδέες από ισχύοντα μοντέλα δεδομένων.
Δομή των Δεδομένων
Ένα αντικειμενοστρεφές μοντέλο δεδομένων βασίζεται στη γενική ιδέα του αντικειμένου (object) και της κλάσης (class). Σύμφωνα με το [Di93], ένα αντικείμενο μπορεί να θεωρηθεί σαν μία τετράδα: <OID, τιμή, κατάσταση, κλάση> και μια κλάση σαν μία εντεκάδα:
OID - Ταυτότητα αντικειμένου (Object identity)
Σαφής ορισμός για την έννοια της ταυτότητας αντικειμένου (OID - object identifier ή object identity), δεν υπάρχει. Θα μπορούσε να αναφέρει κανείς τον ορισμό που δίνουν οι Copeland και Khoshafian [CK86]:
Για να υλοποιηθεί η έννοια της ταυτότητας αντικειμένου, κάνουμε την παραδοχή, ότι υπάρχει ένας (θεωρητικά άπειρος) αριθμός αναγνωριστικών (identifiers), τα οποία ικανοποιούν τις παρακάτω συνθήκες:
Θα μπορούσε κανείς να πει, ότι η έννοια της ταυτότητας αντικειμένου είναι μια σύλληψη, ώστε το κάθε αντικείμενο να έχει μια οντότητα ανεξάρτητη της τιμής του. Έτσι, η ταύτιση και η ισότητα αντικειμένων είναι έννοιες ξέχωρες μεταξύ τους.
Ο τρόπος με τον οποίο η ταυτότητα καθορίζει μονοσήμαντα ένα αντικείμενο, φαίνεται ολοκάθαρα σε δύο ιδιότητες των αντικειμένων: το μοίρασμα αντικειμένων (object sharing) και τις ενημερώσεις αντικειμένων (object updates) [At+89].
ότι η κλάση Person έχει ως χαρακτηριστικά όνομα, ηλικία και ένα σύνολο από παιδιά. Ας υποθέσουμε ότι ο Πέτρος και η Μαρία έχουν από ένα παιδί με όνομα Γιάννη και ηλικία 15 χρονών. Έχουμε δηλαδή τα εξής αντικείμενα:
Είναι δυνατόν, ο Πέτρος και η Μαρία να έχουν το ίδιο παιδί, ή να πρόκειται για δύο διαφορετικά παιδιά. Η παραπάνω περιγραφή είναι ικανή να αποδώσει την πραγματικότητα, από μόνη της, και στις δύο περιπτώσεις. Στην πρώτη περίπτωση, αρκεί τα δύο αντικείμενα να μοιράζονται το κοινό στοιχείο {( Γιάννης, 15, { } )}, ενώ στη δεύτερη, αρκεί να έχουμε δύο ίσα αλλά μη ταυτοτικά αντίγραφα του αντικειμένου {( Γιάννης, 15, { } )}.
Είναι βασικό να επισημανθεί, ότι από άποψη υλοποίησης, η ταυτότητα ενός αντικειμένου είναι μια έννοια που έχει να κάνει κυρίως με το σύστημα, παρά με το χρήστη. Τα αναγνωριστικά που εκχωρούνται είναι συνήθως αόρατα στους χρήστες, και πάντως σίγουρα μη διαχειρίσιμα, καθώς ο χρήστης δεν μπορεί να τα αλλάξει. Για να μπορεί ο χρήστης να διαχειριστεί τα αντικείμενα, τα συστήματα εισάγουν την έννοια του ονόματος (name) του αντικειμένου. Ένας χρήστης, αν θέλει, μπορεί να αναθέσει ένα όνομα σε ένα αντικείμενο, και να το διαχειρίζεται μέσω αυτού. Το όνομα του αντικειμένου μπορεί να ζει μαζί με το αντικείμενο -σε κάποιες υλοποιήσεις- και σε κάποιες άλλες μπορεί να είναι μια "προσωρινή μεταβλητή" -πράγμα που σημαίνει ότι μπορούμε ακόμα και να μεταφέρουμε ένα όνομα από ένα αντικείμενο σε ένα άλλο (κάτι που προφανώς δεν μπορεί να γίνει με την ταυτότητα σε καμία περίπτωση).
Ενθυλάκωση (encapsulation)
Η ιδέα της ενθυλάκωσης προκύπτει από την ανάγκη διάκρισης μεταξύ καθορισμού και υλοποίησης μιας εφαρμογής καθώς και από την ανάγκη για δομή κατά ενότητες (modularity).
Η έννοια της ενθυλάκωσης στις γλώσσες προγραμματισμού προκύπτει από τους αφηρημένους τύπους δεδομένων (abstract data types). Κάθε αντικείμενο έχει ένα τμήμα διαπροσωπείας (interface part) και ένα τμήμα υλοποίησης (implementation part). Το τμήμα διαπροσωπείας είναι ο ορισμός των λειτουργιών που μπορεί να επιτελέσει το αντικείμενο. Το τμήμα υλοποίησης έχει ένα τμήμα δεδομένων (data part) και ένα συναρτησιακό τμήμα (procedural part). Το τμήμα δεδομένων παριστάνει την κατάσταση (state) των δεδομένων και το συναρτησιακό τμήμα την υλοποίηση των διαφόρων λειτουργιών. Δηλαδή:
αντικείμενο = τμήμα διαπροσωπείας + τμήμα υλοποίησης
όπου:
τμήμα υλοποίησης = τμήμα δεδομένων + συναρτησιακό τμήμα
Η μεταφορά της έννοιας της ενθυλάκωσης στις Βάσεις Δεδομένων καθορίζει ότι ένα αντικείμενο ενσωματώνει πρόγραμμα και δεδομένα. Στις σχεσιακές βάσεις, κάθε οντότητα παριστάνεται με μια πλειάδα (tuple), ενώ οι εφαρμογές τρέχουν χρησιμοποιώντας κάποια προστακτική γλώσσα με ενσωματωμένες DML εντολές (ή μια γλώσσα τέταρτης γενεάς). Οι εφαρμογές είναι αποθηκευμένες σε ένα σύστημα αρχείων, ανεξάρτητο της βάσης.
Σε ένα αντικειμενοστρεφές σύστημα κάθε οντότητα καθορίζεται σαν ένα τμήμα δεδομένων και ένα τμήμα υλοποίησης, όπου υλοποιούνται οι διάφορες εφαρμογές που έχουν σχέση με την οντότητα.
Ένα καλό παράδειγμα, για τη διαφορά ανάμεσα στο σχεσιακό και το αντικειμενοστρεφές μοντέλο, είναι η οντότητα "Εργοστάσιο_Αυτοκινήτων" και η υλοποίηση της εφαρμογής "Αύξησε_Παραγωγή_Φορτηγών". Σε μια σχεσιακή βάση, η εφαρμογή "Αύξησε_Παραγωγή_Φορτηγών" θα ήταν ένα εξωτερικό πρόγραμμα. Αντίθετα, σε μια αντικειμενοστρεφή βάση, η οντότητα "Εργοστάσιο_Αυτοκινήτων" θα αποτελούνταν από το τμήμα διαπροσωπείας (το μέσο επικοινωνίας με το χρήστη), το τμήμα δεδομένων (το οποίο θα έμοιαζε αρκετά με την υλοποίηση της οντότητας στο σχεσιακό μοντέλο) και το συναρτησιακό τμήμα, που ανάμεσα στα άλλα, θα είχε και την εφαρμογή "Αύξησε_Παραγωγή_Φορτηγών". Καμιά λειτουργία, πέραν αυτών που καθορίστηκαν στο τμήμα διαπροσωπείας δεν μπορεί να επιτελεστεί. Η παραπάνω θέση αποτελεί ένα από τα πιο σημαντικά στοιχεία για την έννοια της ενθυλάκωσης. Ο μόνος τρόπος για να αποταθούμε στα διάφορα αντικείμενα, και στις μεταβλητές στιγμιοτύπου τους, είναι μέσω των μηνυμάτων που δηλώθηκαν στο τμήμα διαπροσωπείας.
Αν υποθέσουμε ότι έχουμε μια κλάση "Άνθρωπος", με μια μέθοδο "Παρουσιάσου", και ότι για το αντικείμενο "Γιώργος", που τυχαίνει να είναι στιγμιότυπο της κλάσεως "Άνθρωπος", υπάρχει κάπου η κλήση:
Όταν το αντικείμενο "Γιώργος" λάβει το παραπάνω μήνυμα αναλαμβάνει την εκτέλεση της μεθόδου "Παρουσιάσου".
Η ενθυλάκωση ενθαρρύνει ιδιαίτερα την ιδέα της "λογικής ανεξαρτησίας δεδομένων": μπορούμε να αλλάξουμε την υλοποίηση ενός τύπου, χωρίς να φανεί αυτό, στη διαπροσωπεία.
Έτσι, οι διάφορες εφαρμογές προστατεύονται από τις αλλαγές στα χαμηλότερα επίπεδα υλοποίησης.
Συμπερασματικά, η ενθυλάκωση συγκεντρώνει τα εξής χαρακτηριστικά:
Περιορισμοί Ακεραιότητας
Οι περιορισμοί σκοπό έχουν να εξασφαλίσουν την ακεραιότητα των δεδομένων. Στις αντικειμενοστρεφείς βάσεις δεδομένων οι περιορισμοί ακεραιότητας που συνήθως μπορούν να οριστούν είναι οι ακόλουθοι:
ODMG-93
Η επιτυχία των σχεσιακών συστημάτων διαχείρισης βάσεων δεδομένων βασίστηκε αφενός στην απλότητα του σχεσιακού μοντέλου δεδομένων και στην ανεξαρτησία των δεδομένων από τις εφαρμογές, και αφετέρου στην τυποποίηση. Η αποδοχή του SQL standard, το οποίο βασίστηκε στο μοντέλο δεδομένων και τη γλώσσα που πρότεινε η ΙΒΜ (η μεγαλύτερη εταιρεία που αναμίχθηκε από νωρίς στην ανάπτυξη τέτοιων συστημάτων), πρόσφερε μεταφερσιμότητα των δεδομένων και των εφαρμογών, γεγονός που έκανε το σχεσιακό μοντέλο δεδομένων και την SQL τόσο δημοφιλή.
Στην περίπτωση των αντικειμενοστρεφών συστημάτων δεδομένων, η κατάσταση είναι διαφορετική, καθώς η "παιδική τους ηλικία" συνοδεύτηκε από το βασικό πρόβλημα της ανυπαρξίας ενός καλά ορισμένου μοντέλου δεδομένων. Κάθε σύστημα προσέφερε το δικό του μοντέλο δεδομένων. Τα μοντέλα δεδομένων αυτά έμοιαζαν σημαντικά μεταξύ τους, όμως η ομοιότητα δεν είναι αρκετή: στο επίπεδο του μοντέλου δεδομένων χρειάζεται ταύτιση, και όχι απλή ομοιότητα στα βασικά στοιχεία. Το ίδιο συμβαίνει και στο επίπεδο των γλωσσών προγραμματισμού και των ερωτήσεων. Κάθε σύστημα, βασιζόμενο στο δικό του μοντέλο δεδομένων, προσέφερε και τη δική του γλώσσα. Αν και οι γλώσσες προγραμματισμού της βάσης δεδομένων βασίζονταν στις ίδιες κλασικές γλώσσες τρίτης γενιάς (C++, Smalltalk, κλπ.) δεν υπήρχε ταύτιση στα επιπλέον στοιχεία που χρειάζονται για τη διαχείριση των αντικειμένων μιας βάσης δεδομένων.
Το ODMG δεν είναι μια επίσημη επιτροπή τυποποίησης. Συμμετέχουν όμως, σ’ αυτήν, εταιρείες που κατέχουν το 80% της αγοράς των αντικειμενοστρεφών συστημάτων βάσεων δεδομένων. Επιπλέον, οι εταιρείες αυτές έχουν δεσμευτεί να παρέχουν το κοινό αυτό interface από τις αρχές του 1995. Κομμάτια του standard αποτελούν στοιχεία ήδη υλοποιημένα σε κάποια από τα υπάρχοντα αντικειμενοστρεφή συστήματα βάσεων δεδομένων (π.χ. η γλώσσα ερωτήσεων βασίζεται στη γλώσσα ερωτήσεων του Ο2).
Το 1993, τα επτά μέλη του ODMG με δικαίωμα ψήφου ήταν οι εταιρείες Object Design (ObjectStore), Objectivity, ONTOS, O2 Technology, POET Software, Servio Corporation (GemStone), και Versant Technology. Επιπλέον όλες οι εταιρείες που συμμετέχουν ως Reviewer Members έχουν δεσμευτεί να υλοποιήσουν το ODMG-93. Σήμερα, στα 1997, οι εταιρείες αυτές έχουν παραμείνει σχεδόν οι ίδιες (αν και πολλές έχουν αλλάξει τα ονόματά τους) και είναι οι εξής: GemStone Systems, IBEX Computing, O2 Technology, Object Design, Objectivity, POET Software, UniSQL, Versant Object Technology. Πρακτικά, αποχώρησε η Ontos και προσχώρησε η IBEX Computing (που διακινεί το Itasca) και η UniSQL. Στην παρουσίαση του ODMG-93 standard θα βασιστούμε κυρίως στο [Ca95] και κατά δεύτερο λόγο στα [Ki94], [ODMG94]. Όλα τα σχήματα και τα παραδείγματα είναι από το [Ca94] και το [Ca95].
Αρχιτεκτονική του ODMG-93
Τα βασικά στοιχεία της αρχιτεκτονικής του ODMG-93 είναι τα εξής:
Η περιγραφή του ODMG-93 περιλαμβάνει ένα μοντέλο αντικειμένων που είναι μια επέκταση στο μοντέλο αντικειμένων του OMG [OMG97], μια γλώσσα ορισμού αντικειμένων (ODL) που παρέχει ένα μηχανισμό ανεξάρτητο από τις γλώσσες προγραμματισμού για να εκφράσει κανείς το σχήμα μιας βάσης, μια γλώσσα ερωταποκρίσεων αντικειμένων (OQL) που παρέχει ένα δηλωτικό τρόπο προσπέλασης των δεδομένων, σαν μια επέκταση της SQL, και δυο επεκτάσεις αντικειμενοστρεφών γλωσσών προγραμματισμού. Η μια επέκταση είναι αυτή για τη C++ και η άλλη για τη Smalltalk.
Στην παρακάτω εικόνα φαίνεται ο τρόπος, με βάση τον οποίο θα χρησιμοποιείται ένα αντικειμενοστρεφές σύστημα βάσεων δεδομένων, στα πλαίσια της προδιαγραφής του ODMG-93. Ένας διαχειριστής της βάσης γράφει δηλώσεις για το σχήμα της, οι οποίες συγγράφονται στην ODL, ή σε μια επέκταση της γλώσσας προγραμματισμού (PL ODL). Ο προγραμματιστής εφαρμογών γράφει και ένα πρόγραμμα που υλοποιεί την εφαρμογή. Ο κώδικας του προγράμματος αυτού γράφεται σε μια γλώσσα προγραμματισμού (PL), όπως για παράδειγμα, η C++, η οποία επεκτείνεται για να αποτελέσει την γλώσσα προγραμματισμού μιας βάσης δεδομένων. Οι δηλώσεις περνούν από κάποιο προεπεξεργαστή (preprocessor), ο οποίος αφενός παράγει το σχήμα της βάσης και αφετέρου φτιάχνει μια περιγραφή του σχήματος στη γλώσσα προγραμματισμού της εφαρμογής. Ο κώδικας της εφαρμογής και η περιγραφή αυτή μεταφράζονται, δημιουργείται ένα εκτελέσιμο αρχείο της εφαρμογής, το οποίο αφού συνδυαστεί με τη μηχανή του αντικειμενοστρεφούς συστήματος βάσεων δεδομένων (μέσα από ένα πρόγραμμα σύνδεσης - linker) δημιουργεί την τελική εφαρμογή, η οποία και επεξεργάζεται τα δεδομένα της βάσης δεδομένων.
Το Μοντέλο Αντικειμένων του ODMG
Το μοντέλο δεδομένων του ODMG συνοψίζεται ως εξής:
Η ορολογία που χρησιμοποιεί το ODMG δε συμβαδίζει απόλυτα με την ορολογία που έχουμε χρησιμοποιήσει μέχρι εδώ. Η "κατάσταση" ενός αντικειμένου στο ODMG είναι ο όρος για την "τιμή" του αντικειμένου, όπως τον έχουμε χρησιμοποιήσει μέχρι τώρα.
Γλώσσα Ορισμού Αντικειμένων (Object Definition Language - ODL)
Δεδομένου ότι δεν είναι σαφές που θα υλοποιηθεί το σχήμα που θα καθοριστεί στην ODL, η ODL πρέπει να είναι ανεξάρτητη από την οποιαδήποτε γλώσσα προγραμματισμού. Επιπλέον, πρέπει να μπορεί να ενσωματωθεί με ομαλό τρόπο σε γλώσσες όπως η Smalltalk και η C++, πράγμα που καθορίζεται στα αντίστοιχα bindings. Ακολουθεί το παράδειγμα ενός υποτυπώδους σχήματος σε ODL (με έντονα γράμματα φαίνονται οι δεσμευμένες λέξεις της ODL):
interface Person (  extent People) {   attribute String name; attribute Struct Address { Unsigned Short number, String Street, String city_name} address; relationship Person spouse inverse Person::spouse; relationship Set<Person> children inverse Person::parents {order by birth date } relationship List<Person> parents inverse Person::children; void birth (in String name); Boolean marriage (in String person_name) raises (no_such_person); Unsigned Short ancestors (out Set<Person> all_ancestors) raises (no_such_person); void move (in String new_address); };
interface City (   extent cities    key city_code) {   attribute Unsigned Short city_code; attribute String name; attribute Set<Person> population; };
Στο παραπάνω παράδειγμα, ορίσαμε την κλάση Person που μοντελοποιεί ένα άνθρωπο. Τα χαρακτηριστικά της εν λόγω κλάσης είναι το όνομα (name), η διεύθυνση (Address) που αποτελεί μια σύνθετη τιμή, η/ο σύζυγος (spouse) που αποτελεί ένας αντίστροφος δείκτης (inverse) και οι αντίστροφοι δείκτες children και parents, που μοντελοποιούν τα παιδιά και τους γονείς αντίστοιχα. Ακόμα υπάρχουν οι συναρτήσεις birth (ημερομηνία γεννήσεως), marriage (αν κάποιος είναι παντρεμένος ή όχι), ancestors (που επιστρέφει όλους τους προγόνους κάποιου) και move (που αλλάζει τη διεύθυνση κάποιου. Η κλάση Employee κληρονομεί την κλάση Person και την εξειδικεύει προσθέτοντας ένα κωδικό (id) και ένα ετήσιο εισόδημα (annual_salary). Τέλος, η κλάση City έχει τα χαρακτηριστικά city_code (κωδικός), name (όνομα) και population, που είναι ο πληθυσμός της και είναι ένα σύνολο από αντικείμενα της κλάσης Person.
Object Query Language - OQL
Η OQL βασίστηκε στην ήδη υλοποιημένη γλώσσα ερωταποκρίσεων του συστήματος Ο2. Η OQL μπορεί να χρησιμοποιηθεί και σαν ανεξάρτητη γλώσσα, αλλά και σαν υποσύνολο μιας από τις OML. Στη δεύτερη περίπτωση, υπάρχει μια συνάρτηση που εκτελεί την ερώτηση.
Ας υποθέσουμε ότι έχουμε τον τύπο Person με τα χαρακτηριστικά name, birthdate, salary και τη μέθοδο age και τον τύπο Employee που κληρονομεί τον τύπο Person και τον εξειδικεύει με την αναφορά (relationship) subordinates και τη μέθοδο seniority. Επίσης, κάποιο πρόσωπο είναι ο Chairman και μάλιστα υπάρχει κάποιο entry-point για αυτό το αντικείμενο. Τέλος, οι δύο τύποι έχουν τα extents Persons και Employees. Έστω επίσης, ότι υπάρχει και ο τύπος Department, με το χαρακτηριστικό name και την αναφορά employees, η οποία τυχαίνει να είναι και αντίστροφη (στον τύπο Employee υπάρχει η αντίστροφη αναφορά department). Έστω η ερώτηση:
η οποία επιστρέφει, για κάθε υπάλληλο, το όνομά του και τους υφιστάμενούς του που έχουν ηλικία πάνω από 30. Η παραπάνω ερώτηση έχει αποτέλεσμα του τύπουQ
set<struct(name: string, hps: bag<Employee>)>
Παρατηρούμε τα εξής:
Η ερώτηση:
Employee(name: "Pat", id: 0, annual_salary: 100,000)
δημιουργεί ένα αντικείμενο της κλάσης Employee.
Πρέπει να επισημάνουμε ότι το αποτέλεσμα μιας ερώτησης μπορεί να έχει ή να μην έχει ταυτότητα αντικειμένου, ανάλογα με τον τύπο του.
Ας υποθέσουμε και μία κλάση Flowers με το χαρακτηριστικό name.
select p from Persons p, Flowers f where p.name = f.name
Η παραπάνω ερώτηση που βρίσκει όλους τους ανθρώπους που το όνομά τους είναι και το όνομα ενός άνθους, υλοποιεί μια σύνδεση, όπως θα γινόταν και στα σχεσιακά συστήματα.
Στην ερώτηση:
select department, avg_salary: avg(select e.salary from partition x) from Employees e group by department: e.department having count(select * from partition x) > 5 order by department.name
μπορούμε να παρατηρήσουμε ότι διατηρούνται τα group by, having και order by clauses της SQL, τα οποία χαρακτηρίζονται από τα εξής:
Τέλος, στην OQL υπάρχουν και διάφορα άλλα χαρακτηριστικά, τα οποία δεν κρίνεται σκόπιμο να αναφερθούν.[Ca95]
C++ Binding
Στη συνέχεια, θα παρουσιάσουμε ένα από τα χρησιμοποιούμενα bindings, το C++ binding, το οποίο είναι και το πλέον χρησιμοποιούμενο. Όταν αναφερόμαστε στο C++ binding για ODL/OML πρέπει να έχουμε υπόψη μας δύο πράγματα: το C++ binding για ODL είναι μια βιβλιοθήκη κλάσεων και μια επέκταση στη γραμματική της C++. Η βιβλιοθήκη των κλάσεων παρέχει κλάσεις για να υλοποιηθεί το μοντέλο αντικειμένων του ODMG-93. Η επέκταση του συντακτικού της γλώσσας έχει να κάνει με την υποστήριξη αναφορών (relationships) μεταξύ των κλάσεων. Η OML χρησιμοποιείται για την ανάκτηση και την επεξεργασία δεδομένων από τη βάση, και ακολουθεί το συντακτικό της C++. Οι ODL/OML δεν ασχολούνται με τη φυσική αποθήκευση των αντικειμένων, αλλά μόνο με τα λογικά χαρακτηριστικά τους. Ένα πρόσθετο σύνολο δομών, με όνομα physical pragmas, έχει καθοριστεί για να αναλάβει να δώσει στον προγραμματιστή κάποιο έλεγχο πάνω σε αυτά τα ζητήματα.
Τα bindings για τις διάφορες γλώσσες προγραμματισμού καθορίστηκαν με βάση την αρχή ότι ο προγραμματιστής πρέπει να έχει να κάνει με μόνο μία γλώσσα. Αποτελέσματα της αρχής αυτής είναι, ότι υπάρχει μόνο ένα σύστημα τύπων και για τη γλώσσα και για τη βάση δεδομένων, και ότι η ενσωμάτωση των χαρακτηριστικών που οφείλονται στο μοντέλο αντικειμένων της βάσης δεδομένων γίνεται ομαλά.
Για να δηλωθούν τα διαρκή (persistent) δεδομένα στη C++, μια κλάση πρέπει να είναι υποκλάση της κλάσης Persistent_Object. Αυτό σημαίνει, ότι η κλάση αυτή μπορεί να έχει και διαρκή (persistent) και μεταβατικά (transient) -μέσω κάποιων συναρτήσεων- αντικείμενα. Στο παρακάτω παράδειγμα, ακολουθεί η δήλωση ενός στιγμιότυπου (profP) μιας κλάσεως (Professor), το οποίο είναι διαρκές:
Ref<Professor> profP;
Στην παραπάνω εικόνα φαίνεται ο τρόπος με τον οποίο παράγεται μια εφαρμογή, χρησιμοποιώντας το C++ binding για ODL/OML. Ένας διαχειριστής της βάσης γράφει δηλώσεις για το σχήμα της, οι οποίες συγγράφονται στην C++ ODL, η οποία είναι μια επέκταση της C++. Ο προγραμματιστής εφαρμογών γράφει και ένα πρόγραμμα που υλοποιεί την εφαρμογή σε C++, η οποία επεκτείνεται για να αποτελέσει την γλώσσα προγραμματισμού μιας βάσης δεδομένων. Οι δηλώσεις περνούν από κάποιο προεπεξεργαστή (preprocessor), ο οποίος αφενός παράγει το σχήμα της βάσης και αφετέρου φτιάχνει μια περιγραφή του σχήματος στη C++. Ο κώδικας της εφαρμογής και η περιγραφή αυτή μεταφράζονται, δημιουργείται ένα εκτελέσιμο αρχείο της εφαρμογής, το οποίο αφού συνδυαστεί με τη μηχανή του αντικειμενοστρεφούς συστήματος βάσεων δεδομένων (μέσα από ένα πρόγραμμα σύνδεσης -linker) δημιουργεί την τελική εφαρμογή, η οποία και επεξεργάζεται τα δεδομένα της βάσης δεδομένων.
Όπως προαναφέρθηκε, η ODL καθορίζει το σχήμα μιας βάσης, ενώ η OML καθορίζει τη διαχείριση των αντικειμένων, των σχέσεων μεταξύ των κλάσεων, καθώς και των συλλογών (set, bag, list, array). Σε ότι αφορά τις δοσοληψίες ή συναλλαγές (transactions), είναι υποχρεωτικό, κάθε λειτουργία διαχείρισης αντικειμένων να γίνεται μέσα από μια δοσοληψία. Οι δοσοληψίες αποτελούν στιγμιότυπα της ομώνυμης κλάσης και διαθέτουν λειτουργίες commit, abort και checkpoint. Δεν υποστηρίζονται μακρές συναλλαγές, υποστηρίζονται όμως, εμφωλευμένες. Επιπλέον, η OML είναι υπεύθυνη και για τις λειτουργίες σύνδεσης και αποσύνδεσης με μία βάση.
Υπάρχει και μια απεικόνιση της OQL για C++. Οι ερωτήσεις μπορούν να δηλωθούν μέσα σε ένα πρόγραμμα μέσω μιας συναρτήσεως για ερωτήσεις, η οποία παίρνει συμβολοσειρές για ορίσματα. Τα ορίσματα αυτά πρέπει να είναι έγκυρες ερωτήσεις, οι οποίες μεταφράζονται και εκτελούνται στο run-time. Το αποτέλεσμα επιστρέφεται στην παράμετρο "result".
Αντικειμενοστρεφείς επεκτάσεις των Σχεσιακών Συστημάτων (SQL/Object, SQL/Foundation)
Θα στηριχθούμε στα [ΚΜΝ97], [ΜΜ96] για την παρουσίαση αυτή.
Τύποι Ορισμένοι από τον Χρήστη
Οι τύποι που μπορούν να οριστούν από το χρήστη (User Defined Types -UDTs) διαιρούνται με τη σειρά τους σε διάφορες κατηγορίες:
Διακριτοί Τύποι
Οι διακριτοί τύποι (distinct types) αποτελούν την πιο βασική έκφραση των ορισμένων από τον χρήστη τύπων. Ουσιαστικά, αποτελούν μετονομασία ενός βασικού τύπου πηγή (π.χ. DECIMAL, REAL, INTEGER). Στην συνέχεια, θα αναφερόμαστε στον τύπο βάσει του οποίου ορίζεται ένας διακριτός τύπος, ως πηγαίο τύπο (source type) ή βασικό τύπο αναφοράς του διακριτού τύπου. Ο διακριτός τύπος με τον πηγαίο τύπο έχουν την ίδια εσωτερική δομή αλλά παρουσιάζουν εν γένει διαφορετική συμπεριφορά.
CREATE DISTINCT TYPE US_DOLLAR AS DECIMAL (9.2) CREATE DISTINCT TYPE CDN_DOLLAR AS DECIMAL (9.2)
Οι διακριτοί τύποι είναι εφοδιασμένοι από το σύστημα με τελεστές σύγκρισης. Ο ορισμός των τελεστών βασίζεται στους αντιστοίχους ορισμούς του πηγαίου τύπου.
Με χρήση των διακριτών τύπων μπορούμε να ορίζουμε σχέσεις. Για παράδειγμα:
CREATE TABLE SALES (ID INTEGER, US US_DOLLAR, CDN CDN_DOLLAR)
Οι μεταβλητές US, CND βασίζονται στον ίδιο πηγαίο τύπο αλλά ανήκουν σε διαφορετικούς διακριτούς τύπους. Ως εκ τούτου η ακόλουθη έκφραση είναι λανθασμένη.
SELECT * FROM SALES WHERE CDN > US
Για να πετύχουμε την σύγκριση χρησιμοποιούμε την συνάρτηση μετατροπής CND_DOLLAR η οποία μετατρέπει το όρισμα της σε καναδικά δολάρια.
SELECT * FROM SALES WHERE CDN > CDN_DOLLAR(US)
Αντίστοιχα, θα μπορούσαμε να χρησιμοποιήσουμε την συνάρτηση μετατροπής US_DOLLAR.
Αφηρημένοι τύποι δεδομένων
Έκτος από τους διακριτούς τύπους δεδομένων μπορούμε να ορίσουμε και αφηρημένους τύπους δεδομένων (Abstract Data Types, ADTs). Οι αφηρημένοι τύποι δεδομένων αποτελούν οντότητες με συμπεριφορά και ενθυλακωμένη εσωτερική δομή. Ο ορισμός της δομής ενός ATD γίνεται σε SQL. Για παράδειγμα ορίζουμε τον ακόλουθο τύπο:
CREATE TYPE address (street char (30),  city char (20),   state char (2),   zip integer);''
Ενθυλάκωση (Encapsulation)
Όπως έχουμε ήδη αναφέρει, η εσωτερική δομή των αφηρημένων τύπων είναι ενθυλακωμένη. Η πρόσβαση στα πεδία του τύπου περιορίζεται σε συναρτήσεις που ορίζονται στο ορατό μέρος του κάθε αφηρημένου τύπου. Παράλληλα, δεν υπάρχει διάκριση μεταξύ συναρτήσεων, αποθηκευμένων συναρτήσεων (stored functions) και ιδεατών πεδίων (virtual attributes).
Οι συναρτήσεις με τις οποίες μας επιστρέφεται η τιμή ενός πεδίου (observer functions) ή με τις οποίες αναθέτουμε μια τιμή σε κάποιο πεδίο (mutator functions) δημιουργούνται αυτόματα. Για παράδειγμα:
street(address) -> char(30) city(address) -> char(20) state(address) -> char(2) zip(address) -> integer street(address, char(30)) -> address city(address, char(20)) -> address state(address, char(2)) -> address zip(address, integer) -> address
Η κλήση της street(address) θα επιστρέψει ένα πεδίο char(30) που αντιστοιχεί στο πεδίο street του τύπου address. Αντίστοιχα, η κλήση της συνάρτησης street(address, char(30)) θα δημιουργήσει ένα στιγμιότυπο του τύπου address με τιμή πεδίου address την τιμή του char(30).
Δημιουργία Στιγμιότυπων
address -> address
Με την κλήση της παραπάνω συνάρτησης κατασκευάζουμε ένα νέο στιγμιότυπο του τύπου address με κάθε πεδίο του αρχικοποιήμενο στην εξ’ ορισμού τιμή.
Κληρονομικότητα
Σε αντίθεση με τους διακριτούς τύπους, οι αφηρημένοι τύποι μπορούν να οριστούν με βάση έναν ή περισσότερους διαφορετικούς αφηρημένους τύπους (subtyping). Έτσι ο νέος τύπος (υποτύπος) κληρονομεί τα αντίστοιχα πεδία, την συμπεριφορά και τις συναρτήσεις των τύπων ορισμού του (υπερτύποι). Τονίζουμε ότι υποστηρίζεται και πολλαπλή κληρονομικότητα.
CREATE TYPE shape … CREATE TYPE point UNDER shape … CREATE TYPE line UNDER shape …
CREATE TYPE polygon UNDER shape …
Στο παράδειγμα μας ο υπερτύπος είναι ο τύπος shape και οι υποτύποι είναι οι τύποι point, line και polygon.
Χρήση
Οι αφηρημένοι τύποι δεδομένων μπορούν να χρησιμοποιηθούν όπως και οι βασικοί τύποι της SQL. Έστω ότι ορίζουμε ένα ADT με όνομα shape ως εξής:
CREATE TYPE shape (refercing_system INTEGER,  tolerance DECIMAL(8.2),   geometry BLOB(1M));
Με βάση τον παραπάνω τύπο μπορούμε να ορίσουμε και την σχέση:
CREATE TABLE real_estate_info (address address,  price money,   owner char(40),   property shape);
Η διαχείριση των στιγμιότυπων γίνεται με την κλήση των αντιστοίχων συναρτήσεων ορισμού. Χρησιμοποιούμε σαν διαχωριστή πεδίου τις δύο τελείες (dot notation). Για παράδειγμα:
INSERT real_estate_info VALUES (US_DOLLAR(30000),‘Joe Doe’,spatial(10,12,15,20)) SELECT D_mark(price), owner FROM real_estate_info WHERE overlaps(property..geometry, square (5, 5, 25, 25))
Δυνατότητα Αντικατάστασης (Substitutability)
Για να κατανοήσουμε την έννοια της δυνατότητας αντικατάστασης θα χρησιμοποιήσουμε ένα παράδειγμα. Ας υποθέσουμε την ύπαρξη της ακόλουθης σχέσης:
CREATE TABLE real_estate_info (price money,  owner CHAR (40),   property shape);
Ακόμα, ας υποθέσουμε ότι κάνουμε τις ακόλουθες εισαγωγές:
Τα δεδομένα φυλάσσονται ως εξής:
Παρατηρούμε ότι στην στήλη price εκτός από τις τιμές φυλάσσουμε και πληροφορία σχετική με την μονάδα μέτρησης. Ακόμα, αν έχουμε δηλώσει ένα πεδίο σαν τύπο Α, η τιμή του πεδίου αυτού μπορεί να είναι οποιαδήποτε στιγμιότυπο του τύπου Α ή κάποιου από τους υποτύπους του. Έτσι στο πεδίο property του τύπου shape μπορούμε να αναθέσουμε στιγμιότυπα των υποτύπων point, poly και line. Τα στοιχεία του υποτύπου βρίσκονται κατά τον χρόνο εκτέλεσης, γεγονός που απαιτεί καθυστέρηση στην αποτίμηση (late binding).
Το βασικό χαρακτηριστικό της καθυστέρησης στην αποτίμηση είναι η αυτόματη κλήση των συναρτήσεων μετατροπής κατά την εκτέλεση μιας ερώτησης. Για παράδειγμα, κατά την εκτέλεση της ερώτησης
SELECT owner, dollar_amount(price) FROM real_estate_info WHERE dollar_amount(price)<US_DOLLAR(500000);
Επώνυμοι Τύποι Γραμμής (Named Row Types)
Οι τύποι που έχουμε μέχρι τώρα εξετάσει αναφέρονται στον ορισμό νέων πεδίων. Υπάρχουν όμως και τύποι για την αναπαράσταση μιας ολόκληρης πλειάδας μια σχέσης -ενός συνόλου δηλαδή πεδίων. Οι τύποι αυτοί ονομάζονται επώνυμοι τύποι γραμμής (named row types). Γενικά, οι επώνυμοι τύποι γραμμής αποτελούν τύπους ορισμένους από τον χρήστη χωρίς ενθυλακωμένη εσωτερική δομή. Για παράδειγμα:
CREATE ROW TYPE account_t (acctno INTEGER,  cust REF(customer_t),   type CHAR (1),   opened DATE,   rate DOUBLE PRECISION,   balance DOUBLE PRECISION);
Χρησιμοποιώντας τους επώνυμους τύπους γραμμής μπορούμε να ορίσουμε σχέσεις. Για παράδειγμα:
CREATE TABLE account OF account_t (PRIMARY KEY acctno);
Τύποι Αναφοράς (Reference types)
Οι επώνυμοι τύποι γραμμής μπορούν να συνδυαστούν με αναφορές, όπως στο πεδίο cust του τύπου γραμμής account_t. Οι τύποι αναφοράς παραπέμπουν σε δηλώσεις τύπων (στην συγκεκριμένη περίπτωση του τύπου customer_t) και χρησιμοποιούνται κυρίως για να μοντελοποιήσουν σχέσεις μεταξύ επώνυμων τύπων γραμμών.
Οι αναφορές μπορούν να έχουν εμβέλεια (scope).
CREATE TABLE account OF account_t (PRIMARY KEY acctno,  SCOPE FOR cust IS customer);
Σε μια σχέση μπορούμε να ορίσουμε αναφορές μόνο σε μεταβλητές που βρίσκονται στο πρώτο επίπεδο (π.χ. cust). Επιπλέον μπορούμε να χρησιμοποιούμε τους τύπους αναφοράς για να εκφράσουμε ερωτήσεις:
SELECT a.acctno, a.cust->name FROM account a WHERE a.cust->address..city = “Hollywood” AND a.balance > 1000000;
Υποτύποι και κληρονομικότητα
Ένας επώνυμος τύπος γραμμής μπορεί να δηλωθεί σαν υπερτύπος από έναν ή περισσότερους επώνυμους τύπους γραμμής. Οι υποτύποι κληρονομούν τις μεταβλητές και τις συναρτήσεις από τους υπερτύπους τους.
Έστω ότι ορίζουμε ένα τύπο γραμμής για να αναπαραστήσουμε εργαζόμενους.
CREATE TYPE empoloyee (name CHAR (20), salary DECIMAL (10,2))
Βασισμένοι στον τύπο αυτό ορίζουμε δυο νέους για τους προϊστάμενους και τους φοιτητές που εργάζονται το καλοκαίρι.
CREATE TYPE manager UNDER employee (bonus DECIMAL (10,2)); CREATE TYPE summer_stundent UNDER employee (school VARCHAR (30));
Χρησιμοποιώντας τύπους και υποτύπους μπορούμε να ορίσουμε ιεραρχίες σε σχέσεις.
Έστω:
CREATE TABLE employees OF employee; CREATE TABLE managers OF manager UNDER employees; CREATE TABLE summer_students OF summer_student UNDER employees;
Πρακτικά, ιεραρχία στις σχέσεις σημαίνει ότι αν εκφράσουμε ερώτηση που αφορά μια δεδομένη σχέση, θα αναζητηθούν απαντήσεις και σε όλες τις σχέσεις που κληρονομούν από αυτήν. Έτσι, απευθύνοντας ερώτηση στην σχέση employees αυτόματα εξετάζονται και δεδομένα από τις σχέσεις managers και summer_students.
Τύποι Κατηγορημάτων (Type Predicate)
CREATE TABLE real_estate_info (price money,  owner CHAR(40),   property real_estate);
Είναι δυνατό μια ερώτηση, κατά τον χρόνο εκτέλεσης, να ελέγχει το είδος του τύπου που έχει ορίσει ο χρήστης:
SELECT price, owner, property FROM real_estate_info WHERE TYPE(price) IN US_DOLLAR;
Επίσης είναι δυνατό μια ερώτηση να μετατρέψει ένα τύπο σε ένα άλλο υποτύπο του (subtype specification):
SELECT TREAT (price AS US_DOLLAR), owner, property FROM real_estate_info WHERE TYPE (price) IN (US_DOLLAR);
Συναρτήσεις και Μέθοδοι ορισμένοι από τον χρήστη (User Defined Functions-Methods)
Ο χρήστης είναι δυνατό να ορίζει συναρτήσεις, μεθόδους και αποθηκευμένες διαδικασίες (stored procedures) βασισμένες σε κάποιο τύπο (ADTs, row types, κλπ.). Οι δηλώσεις τους γίνονται είτε σε SQL/PSM, είτε σε γλώσσες τρίτης ή τέταρτης γενιάς (3GLs ή 4GLs).
Διαχωρίζουμε τις συναρτήσεις που μπορεί ο χρήστης να ορίσει σε εξωτερικές (external) και σε εσωτερικές (internal). Οι εξωτερικές συναρτήσεις γράφονται και δηλώνονται σε μια από τις καθιερωμένες γλώσσες προγραμματισμού (ADA, C κλπ.). Οι συναρτήσεις αυτές προφανώς υπόκεινται στους περιορισμούς αλλά και εκμεταλλεύονται τις βιβλιοθήκες και την λειτουργικότητα της γλώσσας στην οποία ορίζονται. Παράλληλα, μπορούν να περιέχουν και ενσωματωμένη SQL. Αντίθετα, οι εσωτερικές συναρτήσεις είναι δηλωμένες εξ ολοκλήρου σε SQL, εφοδιασμένη με συναρτήσεις ροής (loop, case, if, for, repeat, return κτλ.) και ανάθεσης (set).