Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

4-facher Primärschlüssel zu umgehen?

Begonnen von Neuling1, Februar 24, 2012, 15:06:18

⏪ vorheriges - nächstes ⏩

Neuling1

Hallo, nochmal eine Frage:
Ich habe eine Tabelle mit Primärschlüssel Autowert, dann Name, Vorname, Geburtsdatum.
Nun können Namen oder/und Vornamen oder auch Geburtsdaten durchaus mehrfach vorkommen. Wollte das Problem lösen, dass die Kombination Name, Vorname und Geb nicht mehrfach vorkommen darf. HAbe versucht einen Index zu setztn. Bekomme die Meldung: Diesen Index gibt es schon.
Nun stelle ich fest, es geht durchaus, einen Namen mit Vorname und Geburtsdatum doppelt einzugeben! Was kann ich tun? Alle 4 Sachen mit Primärschlüssel bestücken?
Danke
Heidi
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll

Jonny

Hallo,
hat deine Tabelle jetzt nur den Autowert als PK?
Wenn ja dann kann in der Tat alles mehrfach vorkommen.

Alle vier Felder als PK geht und dann können keine DS mit gleichen Namen, Vornamen und Geb-Datum vorkommen.
Ich halte allerdings nichts von solche zusammengesetzte Schlüssel (machen das System langsam).
Besser finde ich es das eine Kontrolle durch VBA vorgenommen wird. Bei Gleichheit der drei Felder kann man
dann den entsprechenden DS anzeigen. Oder man kann eine Meldung generiern das es den DS schon gibt und der
Benutzer entscheidet ob der DS verworfen oder gespreichert wird. Und noch andere schöne Sachen.

Gruß

Johann

Wurliwurm

Zitat von: Neuling1 am Februar 24, 2012, 15:06:18
HAbe versucht einen Index zu setztn. Bekomme die Meldung: Diesen Index gibt es schon.
Nun stelle ich fest, es geht durchaus, einen Namen mit Vorname und Geburtsdatum doppelt einzugeben!

Jeder Primärschlüssel erzeugt immer auch einen Index, daher die Meldung.

In Deiner Konfiguration ist nur die Kombination "Autowert, Name, Vorname, Geburtsdatum" auf Eindeutigkeit geprüft, was nicht wegen der Systemgeschwindigkeit, sondern semantisch falsch ist. Damit könntest Du die Kombination "Name, Vorname, Geburtsdatum" immer wieder eingeben.

Die Lösung: Als Primärschlüssel nur die ID, zusätzlich einen eindeutigen Index auf die Felder
"Name, Vorname, Geburtsdatum". Wie der Index angelegt wird, siehe etwa:
http://www.teialehrbuch.de/Kostenlose-Kurse/Access-2010-Basis/4.2.2-Beispiel-81-Einen-Index-über-mehrere-Felder-aufbauen.html#chapter.AC10.example81

oma

Hallo,

Johannes (Wurliwurm) beschreibt das natürlich richtig; eine ID als PK  und Nachname, Vorname sowie Geburtstag als zusammengesetzen Schlüssel!
Und du denkst, du kannst in deiner DB ausschließen, das keiner mit gleichem Namen und Geburtstag je auftreten wird ;D ;D ?

Gruß Oma
nichts ist fertig!

Neuling1

Danke, aber so einen Code kann ich nicht. Ich war der Meinung, dies Problem kan man umgehen, indem man einen Index setzt. Ein Index darf doch bis zu 10 Feldern haben, warum klappt es nicht? Geht sowas nur ab Access 2007?
Also muss ich einen vierfachen Schlüssel setzen.....

Aaaaah, danke, also geht es mit dem Index doch, ich habe es nur falsch gemacht! Ich werde mein Glück probieren!
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll

Stapi

Hallo Neuling

Was @Jonny dir mit dem Schlüssel auch mitteilen wollte, das auch bedenken solltest das mann Namen in Unterschiedlich eingeben kann als kleines Beispiel . z.b Möller oder Moeller somit kannst du zwei Datensätze anlegen für eine Person dort hilft dir der Index auch nicht weiter.

Gruß Stefan
Grüße aus dem schönen NRW
Stefan

ebs17

Zitat von: JonnyIch halte allerdings nichts von solche zusammengesetzte Schlüssel (machen das System langsam).
Besser finde ich es das eine Kontrolle durch VBA vorgenommen wird.
Woran machst Du das "Langsam-Machen" fest?
Dass ein Index beim Schreiben bremst (weil er auch neu geordnet werden muss), ist bekannt. Allerdings kann er das Lesen deutlich beschleunigen, wenn man ihn nutzt. Letzteres ist Grundlage üblicher Datenbankarbeit.

"Kontrolle durch VBA" ... ist nur ein bedingt taugliches Mittel, bei einer Anfügeabfrage kann man diesbezügliches VBA wohl kaum ausführen.
Dagegen wirkt ein eindeutiger Index zuverlässig und dort, wo er eigentlich benötigt wird: Auf Tabellenebene.

@Neuling1:  Nicht vierfacher Schlüssel. Der Autowert bleibt Primärschlüssel für sich, der eindeutige zusammengesetzte Schlüssel auf die drei Felder sorgt für eindeutige Kombinationen.
Da ein Autowert nie doppelt vorkommt, würdest Du
a) wieder gleiche Nachname-Vorname-Geburtstags-Kombinationen zulassen.
b) Ein zusammengesetzter Schlüssel ist beim Verknüpfen innerhalb von Abfragen sehr sperrig, und wer richtige (komplexere) Abfragen schreibt, wird den Ersatz durch einen einfachen PK schätzen.

MfGA
ebs
Mit freundlichem Glück Auf!

Eberhard

Jonny

Hallo,
ebs: ich habe mich da falsch ausgedrückt. Ich halte nichts von Monsterschlüssel da man damit schlecht arbeiten kann.
Wegen VBA: ich war davon ausgegangen das Eingabe über ein Formular geschehen (kenne ich nicht anders).
Und da kann ich tatsächlich sehr gut Plausibilitätsprüfungen machen.

Gruß

Johann

ebs17

#8
Daten gelangen aber nicht nur durch Eingaben über Formular in Tabellen (einen Import tippt man sicher nicht datensatzweise in ein Formular ein), sondern auch über Abfragen, Recordsetanweisungen und manchmal gar per händischer Eingabe direkt in die Tabelle. Dort kann nur ein passend gesetzter eindeutiger Index umfassenden Schutz bieten.

Dass man aber begleitend auch mit eigenen Maßnahmen Duplikate vermeidet, versteht sich von selbst, um
- den User vor irritierenden Systemmeldungen zu bewahren,
- Schlüsselverletzungen zu vermeiden (diese sind auch Fehler).
Solche Maßnahmen können wie bereits gesagt VBA-Prüfungen sein, aber z.B. auch Inkonsistenzprüfungen innerhalb von Anfügeabfragen.

MfGA
ebs
Mit freundlichem Glück Auf!

Eberhard