Μπορεί να ακούγεται λίγο "παιδικό" για αυτή την περιοχή, όμως η απορία μου ξεκίνησε από μια συζήτηση που γίνεται στην περιοχη "Πρώτα βήματα". (http://www.dotnetzone.gr/cs/forums/thread/34788.aspx)

Η ερώτηση που ανέκυψε, μεταξύ άλλων, είναι η εξής: "Μπορώ να έχω σε ένα πίνακα δύο primary keys"; Η απάντηση ήταν, φυσικά, οχι, μια και η έννοια του "primary" δηλώνει ούτως η άλλως μοναδικότητα.

Ετοιμάστηκα να απαντήσω στον ερωτώντα οτι ακόμα και αν το δεύτερο πεδίο προσδιορίζει μοναδικά κάθε γραμμή του πίνακα, η ύπαρξή του και μόνο παραβιάζει τον 3NF. Ομως, ψάχνοντας λίγο παραπάνω είδα τον εξής ορισμό για τον 3NF (wikipedia):

Every non-prime attribute of the table must be non-transitively dependent on every candidate key

Τώρα, η απορία μου είναι απλή: Εφόσον π.χ. στον πίνακα για τον οποίο μιλάμε το πεδίο Α ειναι primary key και το πεδίο Β είναι - ας υποθέσουμε - candidate key (όπως και το Α εξάλλου), και ΔΕΝ υπάρχει μεταξύ τους εξάρτηση, ενώ και τα δύο προσδιορίζουν μοναδικά καθε γραμμή, δεν είναι ορθό, σύμφωνα με τον παραπάνω ορισμό, οτι μπορούμε - θεωρητικά - να τα έχουμε και τα δύο στον ίδιο πίνακα; (Εκτός αν ο ορισμός έχει αποδοθεί λανθασμένα).

Πολλές άλλες αναφορές στον 3NF που διάβασα κόπτονται οτι καθε πεδίο πρέπει να είναι εξαρτώμενο από το PK, μόνο το PK καί τίποτα άλλο εκτός του PK. Ομως, στον παραπάνω ορισμό δεν μιλά για PKs αλλά για Candidate keys. Συνεπώς τα Α και Β είναι candidate keys, και δεν παραβιάζεται ο 3NF αν τον ερμηνεύσουμε έτσι.

Ξέρω οτι είναι θέμα τυπικό και μονο μια και η επικρατούσα άποψη είναι οτι 3NF σημαινει οτι έχουμε ένα PK και όλα "κρέμονται" από αυτό. Αλλά, τελικά, σε θεωρητικό επίπεδο, τι ισχύει;

 

 

 

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

ακόμα και αν το δεύτερο πεδίο προσδιορίζει μοναδικά κάθε γραμμή του πίνακα, η ύπαρξή του και μόνο παραβιάζει τον 3NF

Δεν ξέρω κατα πόσο ισχύει θεωρητικά αυτό που ισχυρίζεσαι, δηλαδή όταν ένα πεδίο είναι μοναδικό σημαίνει ότι δεν εξαρτάται από το PK. Μπορεί να έχεις ταυτόχρονα δύο πεδία μοναδικά και το ένα να εξαρτάται πάντοτε από το άλλο. Ένα απτό παράδειγμα: Μπορείς να έχεις ένα πεδίο ως PK που να είναι ο Αριθμός Ταυτότητας(Μοναδικό Σωστά;). Και μετά να έχεις ένα πεδίο που να είναι Αριθμός Μητρώου ΙΚΑ(Πάλι μοναδικό για όλους). Και όμως δεν μπορώ να καταλάβω που παραβιάζεται η 3NF... Εκτός αν δεν κατάλαβα καλά τι εννοείς...

---

Coding at Mediterranean Acoustics

Η υπόθεση που κάνω σε αυτό το ερώτημα είναι οτι έχουμε δύο candidate keys στον πίνακα. Ητοι, μοναδικά, το καθένα από αυτά προσδιορίζει μοναδικά κάθε γραμμή του πίνακα, όλα τα πεδία εξαρτώνται άμεσα από αυτά τα δύο candidate keys. Η υπόθεση επίσης λέει οτι τα δυό αυτά πεδία ΔΕΝ εξαρτώνται άμεσα ή έμμεσα μεταξύ τους.

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Μμμ, ξέχασα το σημαντικότερο!

Βάσει λοιπόν της υπόθεσης που ανέφερα παραπάνω, έχουμε δύο candidate keys σε ένα πίνακα που το καθένα τους μπορεί άνετα και ισάξια να λειτουργήσει ως primary key. Ομως, κατι τέτοιο, λένε οι νεότεροι ερμηνευτές της...βίβλου του Codd, δεν πρέπει να γίνεται. Λενε οτι θΘα πρέπει το δεύτερο πεδίο να πάει σε άλλο πίνακα, γιατί όλα τα υπόλοιπα πεδία του πίνακα πρέπει να εξαρτώνται "from the key, the whole key and nothing but the key".

Σύμφωνα με τον ορισμό της Wikipedia όμως, που ανέφερα παραπάνω, (και που υποψιάζομαι οτι είναι ο original) το δεύτερο candidate key μπορεί να παραμείνει.

Εκεί είναι και το μπέρδεμα που προσπαθώ να ξεδιαλύνω. Τελικά γιατρέ μου να key κανεις ή να μην key; (πέραν του pk). :)

 

 

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

εδω νομιζω ρωταγα ακριβως το ιδιο πραγμα:
http://www.dotnetzone.gr/cs/forums/thread/33129.aspx  

βρηκα λοιπον καπου: ...ο κανονικος τυπος BCNF παραβιαζεται οταν υπαρχει ενα τουλαχιστον χαρακτηριστικό που εξαρταται λειτουργικα απο καποιο αλλο που δεν αποτελει συνιστωσα του προσδιοριστη-κλειδιου...

αποτι καταλαβα δεν υπαρχει κανενα προβλημα οταν δεν τηρειται αυτος ο κανονας , ειναι ομως ενδειξη του οτι θα πρεπει - θα μπορουσε να δημιουργηθει και αλλος πινακας.

καντε οτι σας βολευει.

ΥΓ..ελπιζω να αναφερομαι στο ιδιο προβλημα

Ο BCNF έρχεται μετά τον 3NF, συνεπώς έχεις πάει ένα ...βήμα πιό κάτω :)

Βασικά όμως η λειτουργική εξάρτηση, αν θεωρήσουμε το παράδειγμα όπως το περιέγραψα, είναι τόσο στο πεδίο Α (primary key) όσο και στο πεδίο Β (candidate key) για όλα υπόλοιπα πεδία του πίνακα. Αρα εδώ αρχίζουν άλλα ερωτήματα! Η τα έχω μπερδέψει πολύ; Βρε πού είναι οι db experts μας; :)

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Σωτήρη, αυτό που σε απασχολεί, με απλά λόγια (και αν κατάλαβα καλά), είναι κάτι σαν το παρακάτω:

Πίνακας: ΕξάρτημαΥπολογιστή

Πεδία: ΕξάρτημαID, ΚατηγορίαID, Περιγραφή, ΣειρΑρΕξαρτ, Slots, ΜητρικήTypeID, ΠεριγραφήΜητρικής

Αν υποθέσουμε ότι κάθε εξάρτημα έχει ένα μοναδικό σειριακό αριθμό (πχ κάτι σαν GUID) τότε το PK είναι το ΕξάρτημαID ενώ παράλληλα το ΣειρΑρΕξαρτ προσδιορίζει και πάλι μοναδικά την κάθε εγγραφή. Τα πεδία  Slots, ΜητρικήTypeID, ΠεριγραφήΜητρικής έχουν νόημα μόνο όταν η εγγραφή αφορά σε motherboard και όχι σε κάρτα γραφικών, οποτε ο πίνακας θα πρέπει να σπάσει σε δύο. Ο πρώτος θα είναι το ΕξάρτημαΥπολογιστή(ΕξάρτημαID, ΚατηγορίαID, Περιγραφή) και ο δεύτερος σε Μητρική(ΣειρΑρΜητρ, Slots, ΜητρικήTypeID, ΠεριγραφήΜητρικής)

Τώρα, όλα τα παραπάνω που λέει ο Codd είναι πολύ καλά αλλά μερικές φορές έρχεται η ώρα να κάνουμε τα στραβά μάτια Δεν μιλάω για την περίπτωση που σπάμε την κανονικοποίηση για λόγους performance (πχ κάνουμε prepopulate lookup πεδία και δημιουργούμε computed columns) αλλά για την προσπάθια να παντρέψουμε το σχεσιακό μοντέλο με το OO μοντέλο.

Για παράδειγμα, έχουμε έναν πίνακα με αυτοκίνητα (Car). Όλα τα αυτοκίνητα έχουν CarID, BrandName, ModelName. Ωστόσο στο OO μοντέλο μας έχουμε το FamilyCar subtype και το SportsCar subtype. Το FamilyCar έχει DrawingHook attribute ενώ το SportsCar έχει Cabrio attribute. Κάτι τέτοιο μπορούμε να το μοντελοποιήσουμε με δύο τρόπους:

Car(CarID, BrandName, ModelName, CarType, DrawingHook, Cabrio)

To πεδίο CarType είναι ο discriminator και έχουμε κάνει την παραδοχή ότι 1=FamilyCar, 2=SportsCar. Όταν έχουμε FamilyCar το πεδίο Cabrio είναι Null και όταν έχουμε SportsCar το πεδίο DrawingHook είναι Null.

O δεύτερος τρόπος είναι να κάνουμε κάτι σαν το παρακάτω:

Car(CarID, BrandName, ModelName)

FamilyCar(CarID, DrawingHook)

SportsCar(CarID, Cabrio)

Το CarID είναι PK σε όλους τους πίνακες και υπάρχει 1:1 σχέση Car<->FamilyCar και Car<->SportsCar

Ξέφυγα λίγο από το αρχικό πρόβλημα αλλά πιστεύω ότι είναι προφανές ότι η πράξη μερικές φορές απέχει από τη θεωρία. Θα μου πείτε, "γιατί να μην σχεδιάζουμε τη βάση πάντοτε με τη δεύτερη τεχνική ώστε να είμαστε Codd-compliant". Έλα μου ντε που μπορεί να χρησιμοποιούμε κάποιο O/R mapper που να καταλαβαίνει ιεραρχίες μόνο όταν απεικονίζονται με τον πρώτο τρόπο

 

---

Vir prudens non contra ventum mingit

Μανο το θεωρητικό θέμα είναι αυτό που περιγράφεις με τα εξαρτήματα υπολογιστή, με τη διαφορά οτι σε θεωρητικό επίπεδο θεωρούμε οτι δεν χρειάζεται να "σπάσει" τίποτα σε δύο πίνακες. Υπαρχουν απλά δύο πεδία που λειτουργούν ως candidate keys και εκ των οποίων το ένα είναι primary key (γιατί έτσι γουστάρουμε) και το άλλο εξακολουθεί να είναι candidate key (και θεωρητικά θα μπορούσε, αν γουστάραμε, να είναι αυτό το primary key).

Οι "σύγχρονες" ερμηνείες του 3NF λένε πρακτικά οτι δεν πρέπει να έχουμε δεύτερο υποψήφιο προσδιοριστή (candidate key) στον ίδιο πίνακα, μια και κάτι τέτοιο θα καθιστούσε κάθε άλλο πεδίο του πίνακα ως διπλά εξαρτώμενο λειτουργικά από δύο (ενα κάθε φορά, βέβαια) και όχι από ένα πεδίο (θεωρώντας οτι όλα τα candidate keys είναι single-field keys).

Οι "παραδοσιακές" ερμηνείες λένε οτι ΟΛΑ τα πεδία πρέπει να εξαρτώνται λειτουργικά και άμεσα (οχι μεταβατικά) από ΟΛΑ τα candidate keys.

Εγώ απλά εντόπισα μια διαφορά στο πώς ερμηνεύουμε σήμερα τον 3NF σε σχέση με αυτά που (ελπίζω να) έλεγε ο Codd. Ο Codd λοιπόν αποδεχόταν την ύπαρξη πολλαπλών candidate keys στον ίδιο πίνακα. Οι σύγχρονοι ερμηνευτές οχι.

Για το παράδειγμα με το αυτοκίνητο, πολύ καλο μεν, αλλά νομίζω οτι ξεφεύγει αρκετά από το αρχικό πρόβλημα και σε ...έχασα κάπου εκεί :)

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

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

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Η θεωρια των ΒΔ για την 3ΚΜ το λεει ρητα:

Ειναι σε 3ΚΜ οταν ειναι σε 2ΚΜ και επιπλεον,
κανενα απο τα κλειδια που δε συμμετεχουν στο σχηματισμο του κυριος κλειδιου δεν εξαρταται συναρτησιακα τόσο απο το πεδια που δε συμμετεχουν στο σχηματισμο του κυριος κλεδιου οσο επισης και απο το κυριος κλειδι.

Αυτο απο εξω ετσι!!(χωρις βιβλιο), και εφοσον περασε μια 7ετια...φανταστειτε ποσες φορες με εκοψε ο ατιμος...