Forum

Forum (https://www.ms-office.gr/forum/)
-   Access - Ερωτήσεις / Απαντήσεις (https://www.ms-office.gr/forum/access-erotiseis-apantiseis/)
-   -   [ Πίνακες ] Σχεσιακές βάσεις δεδομένων - παραδείγματα (https://www.ms-office.gr/forum/access-erotiseis-apantiseis/1092-sxesiakes-baseis-dedomenon-paradeigmata.html)

Meteora 20-04-11 08:18

Σχεσιακές βάσεις δεδομένων - παραδείγματα
 
1 Συνημμένο(α)
Καλημέρα

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




Θα γράψω δυο λόγια για το δικό μου μικρόκοσμο (μικροεφαρμογή) εργασίας με την access-vba. Θεωρώ ότι για να σχεδιαστεί μια βάση πρέπει :
  1. Οι πίνακες να περιέχουν τα απολύτως απαραίτητα πεδία , τα οποία θα εμφανίζουν δεδομένα σε κάθε record.
  2. Όλοι οι πίνακες να συνδέονται μεταξύ τους με αριθμητικά πεδία.
  3. Υπάρχουν πίνακες "πύργοι" και πίνακες "υπηρέτες". Οι δεύτεροι, μέσω comboBox κάνουν λειτουργικούς τους πρώτους...
  4. Όχι μεγάλοι πίνακες. Ο μεγάλος πίνακας είναι πρόβλημα όταν θα θελήσεις να σχεδιάσεις φόρμα (-ες). Με ένα ερώτημα select έχεις βέβαια στα χέρια σου το "ενιαίο πίνακα".
  5. Ξεκινάς την σχεδίαση σε χαρτί. Γράφεις τις οντότητες που θέλεις να διαχειριστείς (τμήματα - σπουδαστές - μαθήματα - βαθμοί). Μετά βλέπεις τα στοιχεία που θα περιέχουν αυτές οι οντότητες. Εδώ δημιουργείς τους πίνακες υπηρέτες (είδος εξέτασης, εθνικότητα,...). Στην συνέχεια συνδέεις τους πίνακες μεταξύ τους (Προσωπικά θέλω να βλέπω τα ID αλλά δεν κάνω χρήση αυτών). Κατα την φάση της σύνδεσης αρχίζεις και φτιάχνεις μια εικόνα για το πως θα εμφανίζεται η οθόνη του χρήστη. Δείτε στο παράδειγμα που επισυνάπτω, ότι ο πίνακας [Μαθήματα] ενώ ξεκίνησε στη σκέψη μου ως βασικός, κατέληξε υπηρέτης.
  6. Η ονοματολογία πεδίων και πινάκων είναι σημαντικό στοιχείο
  7. Όταν σχεδιάζω μια βάση (μικροεφαρμογή) σκέφτομαι να εμφανίσω τέτοια δομή, ώστε κάποιος που ξέρει περίπου όσα εγώ, να μπορεί με μια ματιά να καταλάβει "τι φτιάχνει αυτός ο Χριστιανός". Αυτό σημαίνει απλότητα, λιτή γραμμή,... αυτό πιστεύω ότι είναι τέχνη!
Δίνω τον λόγο σε όποιο μέλος θέλει να προσθέσει οτιδήποτε σχετικό με το θέμα που είναι το 50% σε μια εφαρμογή. ( Είμαι καθηγητής , εργάζομαι σε λύκειο, ασχολήθηκα με εφαρμογές βαθμολογίας, βιβλιοθήκης, απουσιών, δελτίων κίνησης, αδειών,... και έτσι δικαιολογώ πώς έστησα μια βάση δεδομένων βαθμολογίας σε 1h-2h )

Με εκτίμηση

Νίκος Δ.

Υστερολόγιο: Θεωρώ αναγκαίο όλοι να διαβάσουν έστω ένα μικρό βιβλίο σχετικό με σχεσιακές βάσεις δεδομένων. Το διάβασμα αφορά εκείνους που μπορούν να φτιάξουν κάποιες εφαρμογές αλλά και εκείνους που νοιώθουν έτοιμοι να ξεκινήσουν...
Τα παραπάνω με αφαρμή μια μακρά συζήτηση που συνεχίζεται εδώ

Dimitris Ch 20-04-11 18:20

Kαλησπέρα και απο εμενα σ ολο το Forum
Πολυ σωστα τα γράφει ο Νικος και πολυ καλο το παραδειγμα
Εχω ομως να κανω μια παρατηρηση κατα την δικη μου κριση και οπτικη γωνια.
Συνηθως τα ΙD που χρησιμοποιουμε ειναι ενεργα στις δομες μας και οχι απλα αναγνωριστικα νουμερα.
Αυτα ειναι που επι το πλειστον χρησιμοποιουμε για να συνδεσουμε εγγραφες του ενος πινακα με τον αλλο.
Σιγουρα το πεδιο κωδικος το χρησιμοποιουμε κατα κορον σ ολες τις βασεις αλλα ειναι εργαλειο περισσοτερο του χρηστη και λιγοτερο του προγραμματιστη (αν και πολλες φορες μπορει να το χρησιμοποιουν και οι δυο).
Συνηθως (ή και Σιγουρα) ο κωδικος ειναι μοναδικος σ εναν πινακα αλλα πιο πολυ για ευκολια του χρηστη που θελει να εχει μια ταξη στις εγγραφες του και μια ομαδοποιηση πιθανως.
Σε μεγαλες βασεις ομως αποφευγουμε νομιζω δια ροπαλου να ειναι ο κωδικος (που πολλες φορες απαιτειται να ειναι και αλφαριθμητικο), το κλειδι συνδεσης τον πινακων μεταξυ τους.
Θα δωσω ενα παραδειγμα να γινω κατανοητος.
Εχουμε μια βαση με 2 πινακες. Στον ενα πινακα εχουμε προιοντα και στον αλλον τις κινησεις τους.
Τα προιοντα μπορει να ειναι 10 αλλα οι κινησεις που αντιστοιχουν σ αυτα 10 εκατομυρια.
Τι θα γινει αν για καποιο λογω θελω να αλλαξω την κωδικοποιηση στα προιοντα μου...?
Θα πρεπει να αλλαξουν κωδικο προιοντος ολες οι κινησεις. Φυσικα αυτο η Access το κανει αυτοματα αν ενεργοποιησουμε την αυτοματη ενημερωση οταν κατασκευαζουμε την σχεση αλλα νομιζω οτι δεν θα ειναι και το καλυτερο.
Προσωπικα πιστευω οτι κλειδια συνδεσης πρεπει να ειναι πεδια που δεν επεμβαινει ο χρηστης (τα ΙD στο παραδειγμα μας).
Φυσικα ο χρηστης αυτα δεν τα βλεπει. Βλεπει αυτα που χρειαζεται και καταλαβαινει. Αν η συνδεση μας στο παραδειγμα που αναιφερα ηταν ενα ID τοτε ο χρηστης απλα θα αλλαζε κωδικους στα προιοντα του χωρις να χρειαστει καποια περεταιρω ενεργεια απο την βαση. Αυτο εχω να παρατηρησω κατα βαση και πιστευω να εγινα κατανοητος.
Θα ηθελα να προσθεσω παντως οτι με την Access 2007 και μεταγενεστερα τα κλειδια αυτα ΙD μπορουν πλεον να μην ειναι απλοι αριθμοι αλλα GID (αναγνωριστικο αναπαραγωγης οπως αναφερεται).
Αυτο ειναι ενα μοναδικο νουμερο σε δεκαεξαδικο συστημα που αναπαραγεται μοναδικα μεσα απο μια συνθεση πολλων παραμετρων.
Βοηθα αφανταστα οταν συνεννονουμε δομες κινησεων πχ απο υποκαταστηματα και δεν πρεπει να συμπεσουν κλειδια εγγραφων που εισερχονται απο διαφορετικα υποκαταστηματα (servers) στο κεντρικο με συγχρονισμο βασεων η καποια αλλη διαδικασια.
Πιστευω να μην σας κουρασα και να μην σας μπερδεψα.

Φιλικα Δημητρης

Meteora 21-04-11 19:16

Καλησπέρα στην κοινότητα
Δημήτρη,
ανήκεις στην 'ομάδα' των ολιγάριθμων ατόμων, που υποστηρίζουν την χρήση των ID ως κλειδιά στις σχέσεις των πινάκων. Κατά σύμπτωση όλα αυτά τα άτομα γνωρίζουν άριστα τις βάσεις δεδομένων και τους διαχειριστές των βάσεων δεδομένων. Χαίρομαι που γνώρισα ένα ακόμη μέλος αυτής της ομάδας...
Θα περιγράψω ένα σύστημα διαχείρισης δεδομένων, στο οποίο η χρήση ID ως κλειδί θα ήταν απολύτως καταστροφική.
Έστω οτι σε 100-200 σχολεία έχουμε μια φαρμογή Access -σε κάθε σχολική μονάδα, για να εισαχθούν δεδομένα που αφορούν στοιχεία των καθηγητών (Βαθμός, ΜΚ, Ωράριο, ...). Κάθε σχολείο εξάγει τα στοιχεία αυτά σε *.xls. Γίνεται η αποστολή αυτών ( ftp ) και όλο το υλικό συγκεντρώνεται σε κάποιο φάκελο ενός server, προς όφελος της Δ/νσης και των Γραφείων. Μια άλλη εφαρμογή 'στημένη' στα γραφεία, κατεβάζει τα *.xls και εισάγει τα περιεχόμενα σε ένα πίνακα.
Αν ως κλειδί έχουμε [ID] και όχι τον αριθμό μητρώου [Am] του εκπαιδευτικού, τότε η εισαγωγή των *.xls δεν πρόκειται να πραγματοποιηθεί.
Με αυτό το παράδειγμα θέλω να δείξω ότι η προβληματική που αναπτύσσεται σε κάποια διαχείριση - διακίνηση δεδομένων καθορίζει και την σχεδίαση της βάσης.
Γράφεις :
Παράθεση:

Βοηθα αφανταστα οταν συνενώνονται δομες κινησεων πχ απο υποκαταστηματα και δεν πρεπει να συμπεσουν κλειδια εγγραφων που εισερχονται απο διαφορετικα υποκαταστηματα (servers) στο κεντρικο με συγχρονισμο βασεων η καποια αλλη διαδικασια
Αισθάνομαι οτι γράφεις για μια διαχείριση σε κάποιο άλλο επίπεδο, δεν έχω γνώσεις σε αυτό το επίπεδο, τώρα ξεκινώ -πάντα αργά ! - την σχέση μου με SQL server, manager, client...
Υγεία να έχουμε.

Τις ευχές μου για ευχάριστα... απρόοπτα σε όλους αυτές τις ιδιαίτερες ημέρες

Με εκτίμηση
Νίκος Δ.

Dimitris Ch 21-04-11 20:38

Καλησπερα Νικο
Νομιζω (προσπαθωντας να δωσω μια λογικη υπαρξης και χρηστικοτητας των ID), οτι αν πλατιασουμε την συζητηση περισσοτερο θα μπερδεψουμε τους χρηστες που θα ηθελαν να μαθουν να οργανωνουν μια βαση δεδομενων παρα θα τους βοηθησουμε.
Γι αυτο αλλωστε δεν ανεβασα καποιο παραδειγμα ουτε προτεινα καποια διορθωση στο δικο σου.
Αλλωστε μεχρι να φτασουν να σχεδιαζουν μεγαλες δομες θα οργανωσουν οι ιδιοι μεσα στο μυαλο τους σιγα σιγα την μεθοδο με την οποια θα πρεπει να το κανουν.
Επειδη ομως πολλες φορες υπαρχουν ευλογες ερωτησεις του στυλ "και τι χρειαζομαστε το ID", προσπαθησα να δωσω μια λογικη και απλη εξηγηση.
Σαφεστατα και πρεπει να υπαρχουν κλειδια με την εννοια που καταλαβαινει και χειριζεται ο χρηστης αλλωστε αυτο το επισημανα.
Αυτα δεν προτεινω να καταργηθουν. Σιγουρα ο ΑΜ η ο ΑΦΜ κλπ θα συνεχισουν να αποτελουν αυτα τα μοναδικα κλειδια.
Το οτι ομως ενα πεδιο ειναι μοναδικο κλειδι δεν σημαινει οτι ειναι απαραιτητα και το κλειδι συνδεσης. Αυτο το σκεπτικο θελησα να παραθεσω και να αναλυσω.
Και παλι θα μπορουμε να συννενονουμε σχολεια χρησιμοποιοντας αυτα τα μοναδικα κλειδια [ΑΜ] για την εισαγωγη και τον συνδιασμο των δεδομενων αφου πρωτα ορισουμε στην εισαγωγη τι συνδυαζουμε με τι.
Ειναι ακριβως η ιδια διαδικασια δεν χρειαζεται να αλλαξει τιποτε.
Δεν χρειαζεται η βαση να χρησιμοποιει την ιδια μεθοδο "συννεοησης" που χρησιμοποιει για τον εαυτο της, με οτι εξωγενες εισερχεται προς αυτην.
Περισσοτερο αυτες οι λογικες οπως προαναφερα βοηθουν συγχρονισμους και συννενωσεις βασεων και οχι διαδικασιες import που ειναι ελεγχομενες.
Δεν νομιζω οτι στο παρων θεμα πρεπει να επεκταθουμε περισσοτερο προς αυτην την κατευθηνση.
Ανελυσα μονο και μονο το σκεπτικο μου για να λυσω καποιες πιθανες αποριες των χρηστων και να αναφερω δυο λογια για τα κλειδια αναπαρωγης GID μια και το θεμα αφορουσε σχεδιασμο σχεσιακων βασεων δεδομενων.
Πιστευω οτι ολοι μας στο forum εχουμε ενα παρα πολυ καλο παραδειγμα οργανωσης βασης με τη βαση που σχεδιασες και ανεβασες και σ' ευχαριστουμε γι' αυτο

Ευχομαι Καλο Πασχα και Kαλη Ανασταση σ ολους
Φιλικα Δημητρης

Meteora 22-04-11 01:55

1 Συνημμένο(α)
Καλημέρα...

Ανεβάζω μια ακόμη βάση δεδομένων με σκοπό να ωφεληθούν τα μέλη του Forum. Κυρίως απεθύνομαι στα μέλη - που είτε έχουν πρόσφατα ξεκινήσει είτε ετοιμάζονται να φτιάξουν τις πρώτες τους εφαρμογές.
Πιστεύω στην βαρύτητα της καλής σχεδίασης και από την άλλη προβληματίζομαι, διότι ελάχιστες ερωτήσεις γίναν από την αρχή λειτουργίας του Forum, έως σήμερα σχετικά με την σχεδίαση μιας βάσης δεδομένων.
Αυτά...

Με εκτίμηση

Νίκος Δ.


Υστερολόγιο : Δημήτρη καλά τα γράφεις. Σε ευχαριστώ για τις απαντήσεις σου ...

pixelman 24-04-11 19:16

Χρόνια πολλά , Χριστός Ανέστη! Το νήμα που άνοιξες Νίκο είναι πολύ ενδιαφέρον και χρήσιμο για μένα και φαντάζομαι για πολλούς που είναι αρχάριοι στις βάσεις δεδομένων. Κατέβασα το συνημμένο αρχείο, το μελέτησα και θα ήθελα να κάνω κάποιες ερωτήσεις αν μου επιτρέπεις. Αν ήθελα σε κάποιο είδος εξετάσεων του ασθενή να έχω παραπάνω πληροφορίες πχ στην εξέταση ούρων να έχω το ειδικό βάρος και το λεύκωμα ενώ στην αιμοληψία να έχω την αιμοσφαιρίνη και τον αιματοκρίτη πώς θα ήταν η σχεδίαση; Επίσης, θα μπορούσε στον πίνακα ΑΣΘΕΝΕΙΣ να απουσίαζε το πρώτο πεδίο ΚΩΔ_ΑΣΘΕΝΗ και να είχαμε ως πρωτεύον κλειδί τον ΑΜΚΑ ή τον ΑΡ_ΤΑΥΤΟΤΗΤΑΣ;

Dangel82 25-04-11 17:11

Χρόνια Πολλά, Χριστός Ανέστη!

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

Βάζω κι εγώ λοιπόν την γνώμη μου στην κουβέντα σας, ελπίζοντας να γίνω κατανοητός.

Υπάρχουν πολλοί τρόποι να φτιάξεις μια εφαρμογή σε περιβάλλον Access. Απλό παράδειγμα είναι η χρήση σχέσεων ή όχι, άλλοι τις χρησιμοποιούν και άλλοι δεν θέλουν καν να ακούν για αυτές.
Όπως πολύ σωστά ειπώθηκε πιο πάνω ο σωστός σχεδιασμός μιας εφαρμογής ξεκινάει απο το χαρτί και καταλήγει σε εργασία επί του Η/Υ.
Όποιος έχει ασχοληθεί έστω με μια βάση δεδομένων (μιλάμε για δημιουργία) μπορεί να καταλάβει πως φτιάχνοντας πολλά αλλάζουν και άλλα απλά βγάζουν θέματα που αρχικά δεν υπολόγιζες, όπως το παράδειγμα με τον πίνακα μαθήματα που τέθηκε παραπάνω.
Εδώ (και αυτό είναι το μέρος της κουβέντας που κέντρισε το ενδιαφέρον μου) κολλάει πολύ καλά το θέμα των διαφορετικών απόψεων που υπάρχουν σχετικά με το "ID" σε έναν πίνακα.
Προσωπικά πιστεύω πως είναι άποψη του καθενός το πως θα σχεδιάσει την βάση του. Ενα πεδίο "ID" μπορεί να χρησιμοποιηθεί σε όλες (ανεξαιρέτως) τις περιπτώσεις, ακόμα και στην περίπτωση που αναφέρει ο Νίκος με το παράδειγμα του σχολείου.
Οι βάσεις δεδομένων είναι αρχικά τρόπος οργάνωσης των δεδομένων μας, και στην συνέχεια ένας εύκολος τρόπος διαχείρισης δεδομένων.
Δλδ: Στο παράδειγμα του Νίκου, ο τρόπος λειτουργίας του ID όντως ΔΕΝ λειτουργεί σωστά γιατί υπάρχει τεράστια πιθανότητα τα ID όλων των σχολείων να "επανωτίσουν" το ένα με το άλλο, άρα υπάρχει λάθος συλλογή αποτελέσματος.
Τώρα, το κάθε σχολείο ως μονάδα έχει σωστά αποτελέσματα γιατί τα ID του είναι μοναδικά.
Άρα, το λογικό συμπέρασμα που μπορεί να βγεί απο τον παραπάνω συλλογισμό είναι πως το κέντρο συλλογής όλων των πληροφοριών, ΔΕΝ πρέπει να χρησιμοποιήσει την ίδια βάση δεδομένων με αυτή των σχολείων, αλλά κάτι μεγαλύτερο και ποιο σύνθετο.

Συμπέρασμα: Τα πάντα είναι θέμα σχεδιασμού, εαν κολλάμε σε μια λύση γιατί αυτή έχει προταθεί και χρησιμοποιείτε απο το μεγαλύτερο μέρος του συνόλου, τότε απλά ΔΕΝ δημιουργώ, απλά αντιγράφω μεθόδους τρίτων.

Μαθαίνω να σχεδιάζω βάσεις δεδομένων, για εμένα απλά σημαίνει αυξάνω τις γνώσεις μου σε αυτές...

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

Φιλικά, Άγγελος

Meteora 25-04-11 17:34

1 Συνημμένο(α)
Καλησπέρα , Χρόνια Πολλά σε όλους

Αγαπητέ Ευθύμη, η λύση που σε προτείνω παρουσιάζω στο επισυναπτόμενο *.doc Δηλ. προτείνω ένα επιπλέον πίνακα, που θα καταγράφει επιπλέον γνωρίσματα ιατρικών εξετάσεων εφόσον υπάρχει τέτοια ανάγκη.
Ελπίζω η λύση αυτή να σε φανεί χρήσιμη. Καλή συνέχεια...

Με εκτίμηση

Νίκος Δ.

Υστερολόγιο: Άγγελε, σε διαβάζω -με χαρά, μετά την ανάρτηση...

pixelman 25-04-11 20:49

Περίμενα μια λύση η οποία θα σύνδεε το νέο πίνακα ΜΕΤΡΗΣΕΙΣ_ΙΑΤΡΙΚΩΝ_ΠΑΡΑΜΕΤ ΡΩΝ με τον πίνακα ΙΑΤΡΙΚΕΣ_ΕΞΕΤΑΣΕΙΣ_ΑΣΘΕΝΩΝ χωρίς όμως να γνωρίζω με ποιο τρόπο. Με τη λύση που δίνεις, αγαπητέ Νίκο, νομίζω πως δε συνδέονται καθόλου οι 2 προαναφερθέντες πίνακες. Άρα, πώς θα γνωρίζαμε μια συγκεκριμένη ημερομηνία τι αιματοκρίτη είχε ένας συγκεκριμένος ασθενής; Θα μου απαντούσε ίσως κάποιος πως αυτό θα λυνόταν με ένα ακόμη πεδίο «ΗΜΕΡΟΜΗΝΙΑ_ΜΕΤΡΗΣΗΣ» στον πίνακα ΜΕΤΡΗΣΕΙΣ_ΙΑΤΡΙΚΩΝ_ΠΑΡΑΜΕΤ ΡΩΝ. Έτσι, όμως, δε θα είχαμε πλεονασμό δεδομένων; Δηλαδή, μια αιματολογική εξέταση θα έπρεπε να την καταχωρούμε μια φορά στον πίνακα ΙΑΤΡΙΚΕΣ_ΕΞΕΤΑΣΕΙΣ_ΑΣΘΕΝΩΝ και μια (έστω τα πεδία που αφορούν την ημερομηνία και τον κωδ εξέτασης) στον πίνακα ΜΕΤΡΗΣΕΙΣ_ΙΑΤΡΙΚΩΝ_ΠΑΡΑΜΕΤ ΡΩΝ.

Meteora 25-04-11 21:57

Καλησπέρα

Ευθύμη, η σύνδεση των πινάκων γίνεται για να δημιουργηθεί ένα πλέγμα που θα συνδέει τα ΠΑΝΤΑ μεταξύ τους!
Νοσοκομείο - Ονοματεπώνυμα - Εξετάσεις Ασθενή (π.χ. ημερομηνία) - όνομα εξέτασης - και πρόσθετα χαρακτηριστικά εξετάσεων είναι συνδεδεμένα, άρα μπορούν να εμφανιστούν μέσω απλών ερωτημάτων επιλογής.
Να σε ρωτήσω, αν μπορώ να έχω την πληροφορία : "Ποιες εξετάσεις αιματοκτρίτη στο Χ Νοσοκομείο της Θεσ/κης, εμφάνισαν- μετά τις 2/4/2010, τιμές μεγαλύτερες από το 40, για τις γυναίκες που ζουν στα Γρεβενά ;" Ποιά είναι η απάντησή σου ;
Εγώ υποστηρίζω οτι μπορώ, διότι η βάση δεδομένων έχει αυτά τα στοιχεία, έχει την λογική σύνδεση όλων των πινάκων και επομένως μπορώ να έχω αυτή τη πληροφορία. Αν η σχεσιακή βάση δεν μπορεί να συνδέει τα πάντα, τότε δεν είναι σχεσιακή και προφανώς δεν έχω τα πλεονεκτήματά της. Οπότε ξεκινούν οι αλλαγές στη σχεδίαση, αφήνεις λίγο καιρό να περάσει ώστε να έλθουν νέες ιδέες, ψάχνεις, ρωτάς, διαβάζεις,...

Αυτά...
Με εκτίμηση

Νίκος Δ.


Η ώρα είναι 11:35.

Ms-Office.gr - ©2000 - 2026, Jelsoft Enterprises Ltd.


Search Engine Optimization by vBSEO 3.3.2