[el-users] Re: (Αλλαγή δικαιωμάτων αρχείου) Πίνακες «μόνο ανάγνωση» στο LibreOffice Base

Απο: Pantelis  Koukousoulas <pktoss@gmail.com>

Προς: Kostas Oikonomou <kikonomou@yahoo.gr> 
Κοιν.: Ubuntu Λίστα <ubuntu-gr@lists.ubuntu.com>; "users@el.libreoffice.org" 
<users@el.libreoffice.org> 
Στάλθηκε: 11:57 π.μ. Σάββατο, 19 Ιανουαρίου 2013
Θέμα: Re: (Αλλαγή δικαιωμάτων αρχείου) Πίνακες «μόνο ανάγνωση» στο LibreOffice Base
 
2013/1/19 Kostas Oikonomou <kikonomou@yahoo.gr>:
> Το παράδοξο στο αρχείο, είναι ότι υπήρχαν πίνακες με πρωτεύοντα κλειδιά που
> ήταν «Text [VARCHAR]», χωρίς μάλιστα να απαιτείται η αυτόματη εισαγωγή
> δεδομένων! Πιθανό ο όρος για INTEGER να ισχύει για τον τρίτο ή τέταρτο
> πίνακα, ή για κάτι άλλο, που δεν μπορώ να σκεφτώ (δεν είμαι πληροφορικός).

Στο αρχείο που είδα εγώ, τα πεδία με όνομα "ID" που είχαν τύπο Text
δεν ήταν ορισμένα ως πρωτεύοντα κλειδιά (σε όρους γραφικού περιβάλλοντος
δεν υπήρχε "κλειδάκι" στα αριστερά του ID όπως υπάρχει τώρα).
Στους πίνακες που υπήρχε τέτοιο "κλειδάκι" δεν υπήρχε πρόβλημα ως προς
τη λειτουργία της αντίστοιχης φόρμας.

Η απαίτηση το πρωτεύον κλειδί να είναι ντε και καλά INTEGER (δηλαδή
αριθμός) είναι πρόβλημα με το γραφικό περιβάλλον της Base του LibreOffice
δεν είναι κάτι που ισχύει γενικά για τις βάσεις δεδομένων. Οπότε αν κάποιοι
πίνακες δε δημιουργήθηκαν από το γραφικό περιβάλλον της Base αλλά
π.χ., από τη γραμμή εντολών DDL της (ALTER TABLE μπλα μπλα ...)
τότε μια χαρά είναι δυνατόν να υπάρχουν πρωτεύοντα κλειδιά που δεν
είναι INTEGER.

Ελπίζω τώρα να έγινα πιο κατανοητός. Είναι bug του GUI της Base,
όχι γενική απαίτηση στις βάσεις δεδομένων, η γραμμή εντολών SQL
της Base επίσης δουλεύει σωστά.

> Δοκίμασα σε κάποια πρωτεύοντα κλειδιά (αυτά που είχες φτιάξει εσύ) να
> καταργήσω την αυτόματη εισαγωγή δεδομένων, χωρίς να καταργηθεί το πεδίο από
> πρωτεύων κλειδί. Πιθανό στους πίνακες, που αναφέρω πιο πάνω, να είχε οριστεί
> αρχικά το πρωτεύων πεδίο σαν INTEGER και στη συνέχεια να το άλλαξα εγώ, για
> να μπορώ να προσθέτω ότι θέλω (δεν θυμάμαι αν έγινε πράγματι κάτι τέτοιο).

Αν έγινε κάτι τέτοιο αυτό θα μπορούσε να δικαιολογήσει το πρόβλημα.
Το bug είναι τέτοιο ώστε όταν κάποιος αλλάξει τον τύπο του πρωτεύοντος κλειδιού
(έστω "ID") π.χ., σε Text, το εικονίδιο με το κλειδάκι συνεχίζει να
εμφανίζεται αλλά
μόλις σώσεις τον πίνακα και κλείσεις το αντίστοιχο παράθυρο, για κάποιο μυστήριο
λόγο η Base αφαιρεί την ιδιότητα του πρωτεύοντος κλειδιού (κάποιος πανέξυπνος
προγραμματιστής της Sun που πέρασε βάσεις δεδομένων "νύχτα" ευθύνεται γι αυτό
μάλλον :P)

Οπότε μπορεί να άλλαξες τον τύπο του πεδίου, δεν είδες να αλλάζει
τίποτα (συνέχιζε
να δείχνει κλειδάκι) και μετά το έκλεισες και αυτό πίσω από την πλάτη
σου αφαίρεσε
την ιδιότητα "πρωτεύον κλειδί" από το ID το οποίο το κατάλαβες μόνο από τη
συνέπεια που είχε (το ότι κλείδωσαν οι αντίστοιχες φόρμες).

Μη γνωρίζοντας τώρα το τι μπορεί να ευθύνεται για το κλείδωμα των φορμών πού
να πάει ο νους σου ότι μπορεί να φταίει το άλλαγμα του τύπου ενός
πεδίου το οποίο
μάλιστα δεν είδες να έχει και ορατές συνέπειες.

Φαντάζομαι θα έχεις αντιμετωπίσει αρκετά τέτοια περιστατικά στην ιατρική όπου
μια φαινομενικά εντελώς αθώα αλλαγή ή παρέμβαση, που μπορεί μάλιστα
βραχυπρόθεσμα να μην έχει καν ορατά ή μετρήσιμα αποτελέσματα, μακροπρόθεσμα
μπορεί να έχει σημαντικότατες συνέπειες.

> Τέλος, για να μην έχω πρόβλημα, μετέτρεψα όλα τα πρωτεύοντα κλειδιά σε
> INTEGER με αυτόματη εισαγωγή δεδομένων, και πρόσθεσα ένα άλλο πεδίο, με
> τίτλο patient, όπου θα βάζω ένα μοναδικό κωδικό για τον κάθε ασθενή. Στη
> συνέχεια δοκίμασα να ορίσω σχέσεις μεταξύ των πινάκων, με το πεδίο patient
> που θα είναι μοναδικό για κάθε ασθενή, χωρίς επιτυχία. Βγαίνει μήνυμα
> λάθους, στα αγγλικά, που απ' ότι κατάλαβα λέει ότι το πεδίο patient, πρέπει
> να είναι πρωτεύων κλειδί ή να μην έχει διπλές τιμές στον πίνακα (πχ δυο
> τιμές με, ας πούμε, 32). Το πεδίο patient είναι επί του παρόντος «Text
> [VARCHAR]». Πως θα ελέγχει η Base ότι δεν υπάρχουν διπλές τιμές, έτσι που να
> με αφήσει να ορίσω τις σχέσεις; Με την αυτόματη τιμή στο Id, το πρωτεύων
> κλειδί, δεν μπορώ να το χρησιμοποιήσω για τη δημιουργία σχέσης μεταξύ των
> πινάκων.
>
> Ελπίζω να μην σας μπέρδεψα πολύ.

Καθόλου δε μας μπέρδεψες :)

Καταρχήν η αυτόματη τιμή στο ID σε τι σε εμποδίζει από το να το
χρησιμοποιήσεις για τη δημιουργία σχέσης μεταξύ πινάκων; Ίσα-ίσα
που δε χρειάζεται να εφευρίσκεις μοναδικούς κωδικούς για κάθε
ασθενή π.χ., και να σκέφτεσαι αν κάποιο αριθμό τον έχεις
χρησιμοποιήσει ξανά ή όχι.

Το να μην έχει διπλοεγγραφές ένα πεδίο Text δεν είναι πρόβλημα
η base να το ελέγξει. Π.χ., αν ξέρει ότι ως τώρα δεν υπάρχουν
διπλοεγγραφές αρκεί να ελέγχει κάθε νέα καταχώρηση ότι δεν
ταυτίζεται με μια από τις υπάρχουσες.

Αυτό μπορεί να γίνει συγκρίνοντας π.χ., χαρακτήρα προς χαρακτήρα
(φυσικά αυτό είναι πολύ λιγότερο αποδοτικό από το να συγκρίνεις
ακεραίους συνήθως και γι αυτό ο κόσμος προτιμά τα πεδία τύπου
ID να είναι τύπου INTEGER).

Οπότε εν κατακλείδι, το σωστό και πρακτικό είναι να κάνεις
σχέσεις μεταξύ πινάκων με βάση το πρωτεύον κλειδί μόνο.
Το ότι το κλειδί αυτό θα είναι αριθμός (και μάλιστα με αυτόματη
αύξηση) δε θα πρέπει να σε αποθαρρύνει με κάποιο τρόπο
από το να το χρησιμοποιήσεις.

Χαιρετισμούς,
Παντελής

Φίλε Παντελή,

Για να κλείσει το θέμα και να συνεχίσω στη δουλειά μου, αποφάσισα τελικά να αφήσω ανεξάρτητους τους 
πίνακες. Το πεδίο patient θα είναι τέτοιο που να μπορεί να θυμίζει τον κάθε ασθενή, και να μπορεί 
να ταξινομηθεί κατά αύξουσα σειρά. Όταν θα μεταφέρω τα δεδομένα σε Calc, ή σε άλλο τύπο αρχείου, 
έτσι που να μπορούν να μεταφερθούν τελικά σε στατιστικό πακέτο (μάλλον το R statistcs), αυτό θα 
γίνει για κάθε πίνακα ανεξάρτητα. Όλα τα περιστατικά θα ταξινομηθούν σε σχέση με το πεδίο patient 
και θα γίνει η μεταφορά των δεδομένων. Όπου υπάρχουν κενά
 στους πίνακες, πχ ο επανέλεγχος στους τρεις μήνες δεν έγινε, θα μετακινήσω τα δεδομένα του πίνακα 
αυτού πιο κάτω, έτσι που όλα τα στοιχεία στο «patient» να είναι στην ίδια γραμμή ( εννοείται σε 
περιβάλλον Calculus).

Αντιλαμβάνεσε ότι αν μια επίσκεψη δεν γίνει, σε ένα πίνακα τότε, θα έχουμε λιγότερες εγγραφές και 
επομένως η αυτόματη αρίθμιση θα δημιουργήσει σχέσεις μεταξύ διαφορετικών εγγραφών, δηλαδή μεταξύ 
διαφορετικών ασθενών. Με άλλα λόγια, αν ένας ασθενής δεν επανέλθει στους τρεις μήνες για 
επανέλεγχο, τότε τα πρώτα-αρχικά στοιχεία αυτού που δεν επανήλθε, θα αντιστοιχιθούν με τα στοιχεία 
του επόμενου ασθενή (που θα επανέλθει στον επανέλεγχο των τριών μηνών). Τέλος ο επανέλεγχος μπορεί 
να μην γίνει με την ίδια σειρά που έγινε η
 καταγραφή των ασθενών, οπότε και η αυτόματη αρίθμιση θα μπλέξει τα πράγματα.

Συμπερασματικά, η κατάσταση είναι λίγο μπλεγμένη-μπερδεμένη. Δεν θέλω να σπαταλήσω άλλο χρόνο για 
να τη ξεμπερδέψω. Σίγουρα αν ήμουν πιο έμπειρος στη χρήση βάσεων δεδομένων, δεν θα υπήρχε αυτό το 
μπέρδεμα. Επομένως θα δουλέψω τα πράγματα με τον «χειροκίνητο» τρόπο (κάθε πίνακας θα είναι 
ξεχωριστός, έχοντας το πεδίο patient που θα «κωδικοποιεί» κάθε ασθενή). Η κύρια δουλειά αυτής της 
φόρμας είναι η καταγραφή δεδομένων, τα οποία στη συνέχεια θα περάσουν σε στατιστικό πρόγραμμα. Δεν 
με ενδιαφέρει η αναζήτηση δεδομένων. Ο έλεγχος
 των δεδομένων αν καταχωρήθηκαν σωστά, πριν τη στατιστική ανάλυση θα γίνει σε περιβάλλον Calculus.

Το σημαντικότερο ήταν αυτό που έγινε. Το ξεκαθάρισμα στο γιατί δεν μπορούσα να καταχωρήσω δεδομένα 
και η επιτυχής διόρθωση του αρχείου μου, ως και το ότι έμαθα το πως έγινε αυτό.

Πολλές ευχαριστίες

Κώστας Οικονόμου

-- 
Unsubscribe instructions: E-mail to users+help@el.libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/el/users/
All messages sent to this list will be publicly archived and cannot be deleted