Επιστροφή στο Forum : βοήθεια για access
Λοιπόοον, είμαι σχετικά άπειρος με την access και θέλω να κάνω το εξής (θα προσπαθήσω να το περιγράψω οσο πιο αναλυτικά μπορώ):
Σε ένα τουριστικό γραφείο κάθε γκρούπ που ταξιδεύει αντιστοιχεί σε έναν φάκελο.
Σε αυτόν τον φάκελο καταγράφονται όλα τα έξοδα του γκρούπ που στο παράδειγμα μας θα τα ονομάσουμε έξοδαΑ, έξοδαΒ και έξοδαΓ τα οποία στο τέλος αθροίζουμε και βγάζουμε το κόστος του φακέλου.
Το ζητούμενο λοιπόν είναι να κάνουμε μια εφαρμογή που να καταχωρούμε τα έξοδα ανα κατηγορία και να μπορούμε να κάνουμε και αναζητήσεις του στυλ «πόσα έξοδαΒ είχαμε τον μάιο;» ή «ο φάκελος χ πόσα έξοδα είχε συνολικά;»
Προς το παρών έχω δημιουργήσει πίνακες για τις κατηγορίες εξόδων και τις αντίστοιχες φόρμες για καταχώρηση τιμών.
Υποψιάζομαι ότι τώρα χρειάζομαι ερωτήματα για να γίνεται το φιλτράρισμα των εγγραφών αλλά τα έχω μπλέξει λίγο.
Παρακαλώ οποιαδήποτε βοηθεία θα ήταν χρήσιμη.
Ευχαριστω J
O Φάκελος/Ταξίδι είναι ο πρώτος σου Πίνακας
Πιθανά πεδία:
1. ID (autonumber)
2. Προορισμός (text)
3. Ημερομηνία (short date)
Ο Έξοδα είναι ο 2ος
Πιθανά πεδία
1. ID (autonumber)
2. FakelosID (number) -->Foreign key προς Fakelos
3. Ημερομηνία (short date)
4. Ποσό (Currency)
5. Αιτιολόγηση (Text/Memo)
(το ΕξοδοΑ, ΈξοδοΒ, ΈξοδοΓ ουσιαστικά είναι εγγραφές (records) του Έξοδα)
Υπάρχει σχέση ένα-προς-πολλά (one-to-many) από το Φάκελο προς τον Έξοδα. Δλδ στον Έξοδα θα προσθέσεις ένα πεδίο (foreign key) προς τον Φάκελο π.χ. FakelosID
Αφού ολοκληρώσεις τους πίνακες πήγαινε στο Tools->Relationships και δήλωσε τη σχέση των δύο πινάκων (drag το πεδίο ID του Φάκελος στο πεδίο FakelosID του Έξοδα. Τσέκαρε το Enforce Referenctial Integrity και στο Update και στο Delete)
Για να συγκεντρώσεις όλα τα έξοδα τώρα φτιάξε ένα ερώτημα, πρόσθεσε τους δύο πίνακες (η σχέση θα εμφανιστεί αυτόματα) πάτα το tool button Σ (για να γίνει ερώτημα αθροίσματος) και αφού επιλέξεις τα πεδία που θες να εμφανίζονται διάλεξε το Sum στο πεδίο [Ποσό].
Νομίζω είναι αρκετά απλό, αλλά αν έχεις άλλες απορίες, πες.
εγω έχω κάνει διαφορετικούς πίνακες για κάθε κατηγορία εξόδων (εξοδαΑ εξοδαΒ κτλ)
κι αυτό γιατί το κάθε έξοδο έχει 5-6 πεδία.
Για παράδειγμα, οι είσοδοι που πληρώνουν στα μουσεία είναι το ΕξοδοΑ, εχω κάνει τον πίνακα tbl_entrance με πεδία :
1. φάκελος
2. χώρος (πχ ακρόπολη)
3. ημερομηνία
4. άτομα
5. τιμή εισόδου ανα άτομο
6. συνολικό κόστος
και αυτός ο πίνακας κρατάει τα έξοδα για εισόδους χώρων ανα φάκελο
το ίδιο για τα εστιατόρια, τους ξεναγούς κτλ.
Ετσι έχουν βγει 6 tables που πρέπει να συσχετιστούν.....
Αυτό που λές για τα relationships μάλλον θα μου φανει χρήσιμο, αυριο θα κάνω δοκιμές
σε ευχαριστώ πολύ για την βοήθεια
ΥΓ τώρα με έβαλες σε σκέψεις, ίσως τα σβήσω ολα και βάλω τα πάντα σε έναν πίνακα Εξοδα.
Εγώ θα το έκανα όπως λέει ο yiapap με τις εξής αλλαγές:
Θα έφτιαχνα ένα τρίτο table με όνομα Έξοδα_type, με πεδία:
1.ID (autonumber)
2.Type (text, το οποίο θα παίρνει τιμές ΕξοδαΑ, ΕξοδαΒ, ΕξοδαΓ, κτλ)
Στο table Έξοδα θα έβαζα και ένα επιπλέον field το οποίο θα λέγεται Έξοδα_type_ID.
1. ID (autonumber)
2. FakelosID (number) -->Foreign key προς Fakelos
3. Ημερομηνία (short date)
4. Ποσό (Currency)
5. Αιτιολόγηση (Text/Memo)
6. Εξοδα_type_ID (foreign key προς Εξοδα_type)
Έτσι θα μπορείς να κάνεις queries με το τύπο εξόδων (Α,Β,Γ) που θέλεις.
[edit] Αν θέλεις να το κρατήσεις απλό, μην βάλεις τρίτο πίνακα (Εξοδα_type) απλά βάλε το πεδίο Εξοδα_type στο table Εξοδα, το οποίο μπορεί να είναι είτε αριθμός (κωδικός τύπου εξόδων) ή text (όνομα εξόδων). Αυτή η περίπτωση όμως θέλει προσοχή να βάζεις ακριβώς το όνομα των τύπων των εξόδων, για να στα βγάζει όλα τα σωστά records στα queries σου.
Ναι (όλα τα εξοδα σε έναν πίνακα).
Οι πίνακες στη Θεωρία Β.Δ. πρέπει να αντιστοιχούν σε μια "οντότητα" (έννοια) του πραγματικού κόσμου. Είτε πάει στο Μουσείο είτε πάει για φαγητό είναι η ίδια έννοια (για σένα): Η έννοια έξοδο.
Επίσης δεν πρέπει να δημιουργούνται πίνακες για έννοιες που δεν έχουν τέλος. Αν π.χ. αύριο πηγαίνουν οι τουρίστες στα Luna Park, έτσι που το έκανες θα πρέπει να προσθέσεις και έναν πίνακα tbl_LunaPark. Αυτό όμως είναι "no-no". Δεν πρέπει να μπαίνει χέρι Προγραμματιστή εκεί όπου η ενέργεια/απόφαση είναι του χρήστη.
Αν θέλεις να κρατάς ξεχωριστά τις κατηγορίες, μπορείς να κάνεις έναν πίνακα tbl_categories και έναν δεύτερο tbl_CategoryDetails
Categories
1. ID
2. Περιγραφή
Category Details
1. ID
2. CategoriesID
3. Περιγραφή
4. Τιμή
Έτσι στο παραπάνω παράδειγμα
Category
1|Επίσκεψη σε Μουσεία
CategoryDetails
1|1|Είσοδος Ακρόπολης|10€
2|1|Αγορά αναμνηστικών|20€
3|1|Είσοδος Λαογραφικού Μουσείου|5€
(οι πίνακες Category & Category details είναι συνδεδεμένοι (one to many) με το ID<->CategoryID)
Και βέβαια στον πίνακα Έξοδα θα προσθέσεις το πεδίο CategoryID
<edit>
Τώρα που το σκέφτομαι αυτός είναι ο (θεωρητικά) σωστός τρόπος.
Αλλιώς ο πίνακας Έξοδα δεν είναι normalised αφού θα έχεις επανάληψη τιμών
δλδ
1/1/2005,....,Είσοδος Ακροπολης, 10€
7/1/2005,....,Είσοδος Ακρόπολης, 10€
Αυτό όμως είναι πολύ θεωρητικό. Αν σε βολεύει να τα βάλεις όλα στον Έξοδα μη διστάσεις.
moshtef, τα μεγάλα πνεύματα... ;)
Και για να αθροισεις το category Details του yiapap γραφεις στην δημιουργια ερωτηματος σε προβολη σχεδιασης--> προβολη sql.
Select Sum(Category Details.τιμη)
from Category Details
where CategoryDetails.[CategoriesID] between 1 and 3; (αν δεν κανω λαθος.)
Τώρα που το σκέφτομαι αυτός είναι ο (θεωρητικά) σωστός τρόπος.
Αλλιώς ο πίνακας Έξοδα δεν είναι normalised αφού θα έχεις επανάληψη τιμών
δλδ
1/1/2005,....,Είσοδος Ακροπολης, 10€
7/1/2005,....,Είσοδος Ακρόπολης, 10€
Αυτό όμως είναι πολύ θεωρητικό. Αν σε βολεύει να τα βάλεις όλα στον Έξοδα μη διστάσεις.
Δεν είναι απαραιτήτως λάθος η επανάληψη τιμής. Εξαρτάται από το βάρος που έχει στην βάση το πεδίο και η τιμή. Εάν το "Είσοδος Ακροπολης" είναι μία από τις συνολικά 5 τιμές που παίρνει το πεδίο, τότε ίσως να πρέπει να μπει σε ξεχωριστό πίνακα.
Ένα παράδειγμα επαναλήψεων τιμών είναι οι διευθύνσεις. Μπορεί σε έναν κατάλογο ανθρώπων να έχουμε επανάληψη της τιμής "Τσιμισκή"(είδες, το γράφω με δικά σου δεδομένα... :D ). Δεν πειράζει εάν αυτό συμβαίνει, ούτε παραβαίνει τους κανόνες του κ. Codd.
Για παράδειγμα, οι είσοδοι που πληρώνουν στα μουσεία είναι το ΕξοδοΑ, εχω κάνει τον πίνακα tbl_entrance με πεδία :
1. φάκελος
2. χώρος (πχ ακρόπολη)
3. ημερομηνία
4. άτομα
5. τιμή εισόδου ανα άτομο
6. συνολικό κόστος
Ένας πινακας είναι τα γκρουπ.
Δεύτερος είναι οι χώροι. Εάν η τιμή ανά άτομο πάει με τον χώρο, τότε αποτελεί πεδίο αυτού του πίνακος.
Να θυμάσαι ότι στους πίνακες δεν θα έχεις αποτελέσματα που θέλεις να πάρεις. Αυτά θα τα παίρνεις με ερωτήματα. Π.χ., το συνολικό κόστος στο παράδειγμα σου θα το πάρεις από ένωση των δύο πινάκων και τις κατάλληλες πράξεις. Εκεί θ έχεις και την ημερομηνία. Εάν ο αριθμός των ατόμων είναι κατά γκρουπ τότε θα μπει ως πεδίο στον πίνακα "γκρουπ". Επομένως ο τρίτος πίνακας θα έχει
id_επίσκεψης
id_χώρου
id_γκρουπ
υπόλοιπα πεδία παρμένα από τους αντίσοιχους πίνακες
Αυτά όλα είναι θεωρία βάσεων δεδομένων. Η Access έχει δική της σύνταξη που θα πρέπει να μάθεις για να κάνεις τις πράξεις, αλλά η θεωρία είναι πάντα η ίδια.
moshtef, τα μεγάλα πνεύματα... ;).. συναντώνται :thumb_dup
Παιδιά σας ευχαριστώ πάρα πολύ, τώρα το μόνο που απομένει είναι να αρχίσω τα πειράματα και κάτι νομίζω οτι θα βγεί.
Αν έχετε τίποτα καλές ιδέες, θα χαρώ να τις ακούσω….J
@lazar,
Δε διαφωνώ... Και πάλι όμως στο παράδειγμα της Τσιμισκή έχεις το πρόβλημα των Ελληνικών:
Τσιμισκή<>Τσιμισκη<>Tσιμισκή (<--1ο Τ αγγλικό)
Σκέψου το "Είσοδος Ακρόπολης" με πόσους διαφορετικούς τρόπους μπορεί να γραφτεί.
Στο συγκεκριμένο παράδειγμα όπου σίγουρα στο μέλλον θα χρησιμοποιηθεί το συγκεκριμένο πεδίο για ομαδοποιήσεις και με δεδομένο ότι τα γκρουπ πηγαίνουν πάνω κάτω στα ίδια μέρη, νομίζω ότι η κωδικοποίηση (δλδ ο νέος πίνακας) θα είναι χρήσιμος. Το θέμα είναι πόσο άνετα αισθάνεται ο gassim να το κάνει, γιατί με κάθε πίνακα που προσθέτεις, ουσιαστικά αυξάνεις την πολυπλοκότητα της εφαρμογής σου σε όλα τα επίπεδα (ερωτήματα, αναφορές, φόρμες).
@gassim, έχε υπόψη σου ότι ο Query Wizard και γενικά το περιβάλλον ανάπτυξης ερωτημάτων της Access είναι ιδιαίτερα καλό. Έχω φίλους που δημιουργούν ερωτήματα στην Access για να τα χρησιμοποιήσουν μετά σε php και MySQL.
(Αν δεν είχε (το περιβάλλον) και τέτοια εμμονή στο να προσθέτει παρενθέσεις, θα ήταν τέλειο)
Καλές ιδέες έχουμε πάντα. Αν έχεις συγκεκριμένο πρόβλημα, είτε ρώτα, είτε (ακόμη καλύτερα) κάνε ένα zip το mdb και παρέθεσέ το εδώ για να κάνουμε τις προτάσεις απευθείας στο τελικό πρόγραμμα.
Επίσης αν σκοπεύεις να χρησιμοποιήσεις την εφαρμογή σε multiuser περιβάλλον ρίξε ένα σφύριγμα πριν την παραδώσεις για να μιλήσουμε για database splitting (frontend/backend). Θα σου λύσει ΠΑΡΑ ΠΟΛΛΑ προβλήματα.
Όπως είπε και ο yiapap καλό θα ήταν να έχεις την κατηγοροποίηση των εξόδων. Η πολυπλοκότητα μπορεί ίσως να ανεβαίνει στην εφαρμογή σου όμως δεν είναι καθόλου τόσο σημαντική όσο φαντάζεσαι.
Και θα σε βάλει και στο σωστό "normalised" δρόμο. :D
χμ...τι είναι το foreign key απο ένα πίνακα σε έναν άλλον σε τι χρησιμεύει και πώς ορίζεται;
Επίσης πώς γίνεται κάποιο πεδίο να παίρνει αυτόματα το πηλίκο ή το άθροισμα δυο άλλων πεδίων;
Sorry για τις χαζές ερωτήσεις...αλλα ξέρετε, ρωτώντας πάς στην Πόλη :)
χμ...τι είναι το foreign key απο ένα πίνακα σε έναν άλλον σε τι χρησιμεύει και πώς ορίζεται;
Δύσκολο να μάθεις relational databases σε ένα φόρουμ. Εάν δεν γνωρίζεις τι είναι "FK" σημαίνει ότι είσαι στο μηδέν. Γι' αυτό δεν σκέφτηκες να βάλεις τους "Χώρους Επισκέψεων" σε χωριστό πίνακα. Έτσι, μάλλον χρησιμοποιείς την Access σαν Excel.
To begin with...
http://www.frick-cpa.com/ss7/default.htm
Περιεκτικό και συνοπτικό tutorial
κυρίως αυτό σε ενδιαφέρει
http://www.frick-cpa.com/ss7/Theory_TOC.asp
http://www.acm.org/classics/nov95/toc.html
Η θεωρία του Codd που άνοιξε τον δρόμο για τις σχεσιακές βάσεις δεδομένων (θα πρέπει να αναφέρεται και στο παραπάνω).
χμ...τι είναι το foreign key απο ένα πίνακα σε έναν άλλον σε τι χρησιμεύει και πώς ορίζεται;
Επίσης πώς γίνεται κάποιο πεδίο να παίρνει αυτόματα το πηλίκο ή το άθροισμα δυο άλλων πεδίων;
Ακόμα να πω ότι, οι δύο παραπάνω ερωτήσεις είναι εντελώς διαφορετικές. Εξηγούμαι:
η πρώτη αφορά στη θεωρία των βάσεων. Βλ. links παραπάνω.
Η δεύτερη έχει να κάνει με το front-end της Access, δηλ. είναι συγκεκριμένη για το πρόγραμμα 'Access'.
Για να κάνεις σωστό σχεδιασμό μιάς βάσεως, θα πρέπει να μάθεις το πρώτο μέρος (back-end). Μετά θα σε απασχολήσει το πρακτικό μέρος, δηλ. η σωστή σύνταξη ώστε να διαιρέσεις τα δύο πεδιά και ό,τι άλλο. Δυστυχώς, όλα αυτά θέλουν χρόνο, μην ξεχνάς όμως ότι οι βάσεις δεδομένων είναι από τα δυσκολώτερα πράγματα ως σύλληψη και σχεδιασμό στην πληροφορική. Θυμάμαι στο πρώτο βιβλίο για MySql που διάβασα έγραφε ότι, όταν σχεδιάζετε βάσεις δεδομένων θα καταναλώνετε τον περισσότερο χρόνο σας στον σχεδιασμό της βάσεως. Τότε δεν το είχα "πιάσει" και μου είχε φανεί υπερβολή. Σήμερα ξέρω ότι είναι έτσι. Εάν πάντως τα πήγαινες καλά με τις έννοιες των συνόλων στα μαθηματικά σημαίνει ότι σου πηγαίνει η θεωρία των RDB. Αυτά που ρωτάς με το FK είναι οι αντιστοιχίες των συνόλων, για παράδειγμα (αμφιμονοσήμαντες κλπ., εάν τα θυμάσαι από το σχολείο).
Αν και θα συμφωνήσω με τον Lazar, ότι αυτό που ρωτάς είναι θεμελιώδες της θεωρίας Β.Δ. την οποία θα πρέπει να διαβάσεις, θα προσπαθήσω να κάνω μια προσέγγιση.
Τι είναι το Foreign Key;
Το Foreign Key είναι, ουσιαστικά, ο δεσμός ενός πίνακα με έναν άλλον.
Έστω ότι έχεις 2 πίνακες: Τον πίνακα Κατηγορίες_Εξόδων και τον Έξοδα.
Προφανώς κάθε εγγραφή στον πίνακα Έξοδα ανήκει σε μια (και μόνο μια ας υποθέσουμε) Κατηγορία Εξόδων. Εδώ δλδ έχεις μια σχέση ένα προς πολλά (αμφιμονοσήμαντη που είπε ο lazar).
Πως όμως θα συνδέσεις τους 2 πίνακες ώστε η εγγραφή σου στον Έξοδα να δηλώνει αυτή τη σχέση;
Η λύση είναι να προσθέσεις ένα πεδίο στο οποίο οι τιμές που θα δίνεις να αντιστοιχούν σε μια (και μόνο μια) εγγραφή στην Κατηγορία_Εξόδων.
Έτσι αν ο πίνακας Κατηγορία εξόδων έχει πεδία/τιμές:
ID|Περιγραφή|Υπεύθυνος|ΦΠΑ
1|Είσοδοι σε Μουσεία|Γιώργος|9%
2|Γεύματα|Γιάννης|19%
3|Τουρ|Κώστας|19%
4|Κέντρα Διασκέδασης|Γιώργος|19%
τότε θα πρέπει σε αυτόν τον πίνακα να βρεις ποιο πεδίο χαρακτηρίζει μοναδικά την εγγραφή (είναι δλδ το Primary Key (PK) του πίνακα).
Η απάντηση στον παραπάνω είναι προφανής αφού ήδη έχω προσθέσει το πεδίο ID. Θα μπορούσα όμως να χρησιμοποιήσω το πεδίο [Περιγραφή] θεωρώντας ότι δεν υπάρχει περίπτωση 2 κατηγορίες να έχουν την ίδια περιγραφή.
Δεν το κάνω γιατί αποφεύγουμε (για λόγους βελτιστοποίησης/απλότητας) να χρησιμοποιούμε text πεδία ως PK
Ας υποθέσουμε τώρα ότι ο πίνακας Έξοδα έχει εγγραφές που πρέπει να συσχετιστούν με μια κατηγορία εξόδων. Δλδ έχει πεδία
ID|Κατηγορία|Ημερομηνία|Ποσό
1|1|1/1/2005|10€
2|1|7/1/2005|10€
3|2|7/1/2005|20€
Τι λέει ο παραπάνω πίνακας; Ότι την 1η Ιανουαρίου 2005 εμφανίστηκε ένα έξοδο 10€ που ανήκει στην Κατηγορία 1. Δλδ είναι είσοδος σε Μουσείο που την οργάνωσε ο Γιώργος.
Στις 7 Ιανουαρίου πάλι ο Γιώργος πήγε ένα γκρουπ σε Μουσείο και μετά (3η εγγραφή) ο Γιάννης τους πήγε για γεύμα.
Όλα αυτά τα καταλαβαίνω επειδή στο πεδίο [Κατηγορία] χρησιμοποιώ το PK του πίνακα Κατηγορία_Εξόδων για να κάνω τη σύνδεση. Έτσι λέμε ότι το πεδίο [Κατηγορία] είναι Foreign Key του πίνακα Κατηγορία_Εξόδων στον πίνακα Έξοδα. Για να γίνεται πιο κατανοητό αυτό θα μπορούσα να ονομάσω το κλειδί [Κατηγορία_ΕξόδωνID] ώστε με μια ματιά να ξέρω ότι αυτό είναι foreign key που χρησιμοποιεί το πεδίο ID του πίνακα Κατηγορία_Εξόδων.
Φυσικά ο πίνακας Έξοδα θα μπορούσε να έχει ΟΛΑ αυτά τα στοιχεία δλδ να είναι της μορφής:
1|Είσοδοι σε Μουσεία|Γιώργος|9%|1/1/2005|10€
2|Είσοδοι σε Μουσεία|Γιώργος|9%|7/1/2005|10€
Όμως σε αυτή την περίπτωση ο χρήστης της εφαρμογής μου θα έπρεπε να πληκτρολογεί ΚΑΘΕ φορά όλα τα στοιχεία του πίνακα. Και φυσικά θα ρίσκαρα ότι σε κάποια φάση θα έκανε κάποιο λάθος πληκτρολόγησης (π.χ. αντί για 9% θα πληκτρολογούσε 19% για είσοδο σε μουσεία).
Επίσης σκέψου ότι αυτός ο πίνακας σε 2 χρόνια θα είχε εκατοντάδες επαναλαμβανόμενα πεδία. Το "Είσοδοι σε Μουσεία","Γιώργος","9%" θα πρέπει να επαναλαμβάνονται τα ίδια και τα ίδια συνέχεια. Αυτό σημαίνει πιο μεγάλη βάση, και βέβαια μικρότερη ταχύτητα επεξεργασίας.
Η παραπάνω μέθοδος (όταν δλδ βλέπουμε τις όμοιες τιμές πεδίων) είναι η κλασσική "μπακάλικη" μεθοδος να καταλάβουμε ότι η σχεδίαση της Β.Δ. μας είναι λάθος. Που βασικά σημαίνει ότι δεν κάναμε αυτό που λέει ο lazar (για το χρόνο και την προσοχή στη σχεδίαση ΠΡΙΝ ανοίξουμε το περιβάλλον προγραμματισμού μας)
Πως ορίζουμε ένα foreign key (FK)
Αυτό είναι απλό. Κατ' αρχήν πρέπει να δούμε ποιος πίνακας είναι από ποιά πλευρά στη σχέση "ένα-προς-πολλά". Στο παράδειγμα κάθε Κατηγορία_Εξόδων έχει πολλά έξοδα, ενώ κάθε Έξοδο έχει μια (και μόνο μια) Κατηγορία_Εξόδου.
(εδώ θα κάνω μια παρένθεση για να προσθέσω ότι πριν από ΟΤΙΔΗΠΟΤΕ άλλο πρέπει να έχεις εξασφαλίσει ότι η σχέση είναι πράγματι "ένα-προς-πολλά". Αν κάνεις λάθος και η σχέση είναι "πολλά-προς-πολλά" τον ήπιες! Χαρακτηριστικό "επικίνδυνο" παράδειγμα σχέσης Πολλά-Προς-Πολλά είναι η σχέση Αυτοκίνητο-Ιδιοκτήτης. Κάθε αυτοκίνητο λέμε έχει έναν ιδιοκτήτη, ενώ κάθε ιδιοκτήτης μπορεί να έχει πολλά αυτοκίνητα, χτίζουμε τη βάση μας, κάνουμε την εφαρμογή, όλα πάνε μια χαρά και ξαφνικά εμφανίζεται ένα αυτοκίνητο με 2 ιδιοκτήτες! Σε αυτή την περίπτωση (σχεδόν) τα μαζεύεις και φεύγεις, ειδικά αν έχεις ολοκληρώσει την εφαρμογή. Η αλλαγή μιας σχέσης πολλά-προς-πολλά σε ένα-προς-πολλά είναι εξαιρετικά επίπονη αν γίνει εκ των υστέρων!)
Επανερχόμαστε μετά την παρένθεση:
Άρα ο Κατηγορία_Εξόδου είναι από την πλευρά "ένα", ο Έξοδα είναι από την πλευρά "Πολλά"
Πάντα σε μια τέτοια σχέση από την πλευρά "Ένα" πρέπει να υπάρχει ένα PK και από την πλευρά "Πολλά" ένα FK.
Επομένως, το επόμενο βήμα μας είναι να προσθέσουμε ένα πεδίο που θα παίζει το ρόλο του FK στον [Έξοδα]. Αυτό είναι το Κατηγορία_εξόδωνID. Ο τύπος του πεδίου πρέπει να είναι ίδιος με τον τύπου του PK με το οποίο θα το συνδέσουμε. Εδώ θεωρώ ότι το ID είναι Autonumber άρα το Κατηγορία_εξόδωνID θα το ορίσω ως Numeric. Αν ήταν text (που είπαμε το αποφεύγουμε) τότε το Κατηγορία_εξόδωνID θα το όριζα ως text.
Αφού φτιάξουμε το πεδίο και ορίσουμε τον τύπο του πρέπει κάπως να δηλώσουμε αυτή τη σχέση. Η MS Access έχει γι αυτό το σκοπό το Relationships (Tools->Relationships). Την πρώτη φορά που θα το ανοίξεις θα είναι κενό. Κάνε δεξί κλικ οπουδήποτε και επέλεξε Show All. Όλοι οι πίνακές σου εμφανίζονται. Για να δημιουργήσεις μια σχέση κάνε κλικ στο PK του πίνακα της πλευράς "Ένα" (Κατηγορία_Εξόδων) και drag επάνω στο FK (πεδίο Κατηγορία_εξόδωνID του πίνακα Έξοδα).
Θα σου εμφανιστεί ένα παράθυρο που θα επαληθεύει τα 2 πεδία (αριστερά το PK, δεξιά το FK) και στο οποίο μπορείς να δηλώσεις κανόνες Referential Integrity. Πρόσεξε ΠΟΛΥ του κανόνες που θα ορίσεις, ειδικά αν κρατάς οικονομικά στοιχεία! Αν δλδ επιλέξεις "Enforce Referential Integrity" και τσεκάρεις και το Update και το Delete τότε αν στο παραπάνω παράδειγμα σβήσεις την εγγραφή 1 ("Είσοδοι σε Μουσεία") του πίνακα Κατηγορία_εξόδων τότε ΑΥΤΟΜΑΤΑ θα σβηστούν και ΟΛΕΣ οι συσχετισμένες εγγραφές του πίνακα "Έξοδα"!!!
--------------------
Ερώτηση 2: Πως κάνω ένα πεδίο να παίρνει το άθροισμα 2 άλλων;
Απάντηση: Δεν κάνεις τέτοιο πεδίο εκτός αν είναι τεχνικά επιβεβλημένο. Αν π.χ. μαζεύεις χιλιάδες εγγραφές ανά λεπτό σε πραγματικό χρόνο σε προσωρινό πίνακα και χρειάζεται τελικά να αποθηκεύσεις μόνο κάποιον μετασχηματισμό αυτών των τιμών.
Το άθροισμα που λες (ή το πηλικό/γινόμενο/οτιδήποτε) το υπολογίζεις "στο φτερό" (on-the-fly) όταν και αν σου χρειαστεί. Ο υπολογισμός αυτός μπορεί να γίνει σε οποιοδήποτε Ερώτημα, σε οποιαδήποτε Φόρμα, σε οποιαδήποτε Αναφορά ή ακόμα και στον κώδικα On_Click ενός πλήκτρου.
Γενικά ως αρχή "δεν αποθηκεύουμε δευτερογενή στοιχεία" δλδ δεδομένα που μπορούν να προκύψουν από άλλα "πρωτογενή" δεδομένα.
Όπως είπα παραπάνω υπάρχουν εξαιρέσεις τόσο τεχνικές όσο και διαδικασιών. Ένα παράδειγμα τέτοιας διαδικασίας είναι το κλείσιμο του μεσημεριανού ταμείου μπορεί να απαιτεί την αποθήκευση μιας εγγραφής με το τελικό ποσό, παρά το ότι οι πρωτογενής εγγραφές (τιμολόγια) είναι καταχωρημένες στο σύστημα.
Ουφ...
<ταλαιπωρημένο smilie>
yiapyiap είσαι όλα τα λεφτά, σε ευχαριστώ πολύ.
(smile ευγνωμοσύνης)
Foreign key ειναι ενα κλειδι που σε καποιον αλλο πινακα ειναι πρωτευον κλειδι και το προσθετεις στον νεο πινακα ωστε να κανεις τη συσχετιση με τον αλλο.
Δεν το οριζεις αν εννοεις να βαλεις "κλειδακϊ" οπως βαζεις στο πρωτευον κλειδι.
(ελπιζω να μην κανω λαθος και εγω αρχαριος ειμαι)
Edit:οπ sorry δεν ειδα καθολου μερικες απαντησεις
@ ADSLgr.com All rights reserved.