Om den enda nycklen som finns i tabeller i en databas är en (Identity) räknare kan databasen då någon gång nå högre än första normalformen?

Ja, första klarar den ju, det är svårt att inte klara...
Den andra måste den väl rimligtvis kunna utan större problem.
Kika på http://en.wikipedia.org/wiki/Database_normalization

Hur vanligt är det att genomgående använda räknare som är ensam nycklar i tabeller.
Man kanske når en högre teoretisk normalform men informationen i tabellerna får en "lägre" normalform. Exempelvis så kan ju ett bilregister bli.

Fordon (id, reg)
1, ABC 123
2, DEF 312
3, ABC 123

Ägare (id, fordonId , ägare)
1, 2, 'Kalle Kula'
2, 2, 'Kalle Kula'
3, 3, 'Sven Svensson'
4, 1, 'Greger Person'

(fordonID relation till fordon id)

Om du har ordentliga foreign keys så kan du ju bryta ut allt, och har du vettiga constraints så måste det väl funka.

Frågeställningen är lite märklig, hur har den uppstått?

Jag har fått en databas i knät där det är räknaren som är nyckel i alla tabeller. Det finns inga constraints och i stort sätt alla fällt tillåter null. Jag är bara lite kritisk till hur vi skall kunna få någon kvalitet på data i denna databas.

Man bör inte alltid sträva efter en full normalisering av en databas trots det som lärs ut på högskolor och liknande, ett reallife exempel är den databas jag jobbar i nu som är fullt normaliserad och i det närmaste perfekt på papperet, den är vacker och logisk att titta på men närman man använder sju fält (primärnyckeln i tabell 1) för att binda ihop en tabell med en annan tabell som i sin tur är bunden till en tredje på sex fält är det inte så roligt att skriva sql'n längre.

Sunt förnuft bör råda och får man en databas i knät där sunt förnuft icke har rådit så måste man ta mod till sig och kasta den hårt i huvudet på människan som gjort den.

Jo det är ju dit jag försöker komma... (till sunt förnuft). Har du 7 primärnycklar i en tabell så tycker inte jag att det är sunt förnuft :-)

Högskolor lär väl inte alls ut att man ska normalisera så långt som möjligt (åtminstone inte min).

Syftet med normalisering är ju väldigt jordnära, man vill undvika anomalier. Varje nivå upp (åtminstone över 3) ger nya typer av anomalier, och tar bort några. Vad man vill är att hitta en nivå där databasens design implicerar så vettiga krav som möjligt.

Mitt mål är att databasen minst skall kunna hålla reda på att den inte får dubbletter av "samma post". Det tycker inte jag man uppnår genom att sätta räknare som primärnyckel....

Jodå det går bra att undvika dubletter ( i det avseeende du menar) även om man har räknare. Man kan använda constraints.

Bara för att sju fält tillsammans bildar en sammansatt kandidatnyckel (d.v.s. kan potentiellt väljas som primärnyckel) så behöver man faktiskt inte välja en sådan kandidatnyckel som primärnyckel.
Man kan istället välja en surrogatnyckel (t.ex. en automatisk räknare) som primärnyckel.
(och då blir den den sammansatta kandidatnyckeln med sju fält istället en sekundärnyckel)

Om databasen är normaliserad till tredje normalformen så lär man f.ö. uppnå femte normalformen genom att inte använda några sammansatta primärnycklar:
http://www.inconcept.com/jcm/September2004/Pascal.html
> Relational tables ... without composite keys that are in 3NF are also fully normalized (in 5NF*)

Dessutom (vilket är mycket viktigare än att uppnå 5NF, och som även redan har påpekats) så blir det mindre jobbigt att joina om alla primärnycklar (och därmed också främmande nycklar) består av endast ett fält istället för att vara sammansatt med flera fält.

Det är INTE på det viset att man får en ickenormaliserad databas genom att introducera surrogatnycklar.
Om någon har valt att använda sammansatta primärnycklar (bestående av naturliga fält som tillsammans är unika, istället för ett enda artificiellt unikt fält) så är det alltså ett val som någon har gjort, men det är inget som kan skyllas på ett krav/önskemål på en normaliserad databasstruktur, eftersom man alltid har möjlighet att lägga till en surrogatnyckel utan att försämra normaliseringen (och som sagt, man till och med lär förbättra den med en icke sammansatt nyckel)

/ Tomas

Tack Tomas för klargörandet, jag har fått den databsen i knät från en konsult som lyfter 1250 kronor i timmen från vårat företag och totalt förkastat större delen av modellen samt idiotin att använda de naturliga nycklarna, en typisk fråga som kopplade ihop fyra tabeller kunde bli runt 2000 bytes stor och det utan andra urvalskriterier än sammankopplingen.

Lite fel av mig kanske att blanda in normalisering när det egentligen inte var det jag ville ha svar på :-)

Exempelvis om om jag har följande 2 tabeller.

ProduktGrupp(idGrupp, namn)
ProduktPris(Namn, idGrupp, pris)

Kan jag lösa så att Namn, idGrupp i ProduktPris tabellen tillsamans är unika (så att inte samma produkt kan ha två pris, men olika produkter kan ha samma namn om de tillhör olika grupper) utan att sätta båda som nycklar?

Ja, med unique constraints.

Något i stil med
CONSTRAINT NoDuplicates UNIQUE (Namn, idGrupp);

Du kan sätta en constraint på att de två fälten tillsammans ska vara unika, så det är absolut inga problem

Nästa gång får du nog vara betydligt snabbare, Thomas, så här långt efter kan du inte svara... ;)

Saken blir ju att i mitt exempel ovan så kan jag ju inte ha någon primärnyckel alls (om jag inte lägger till en räknare) om unique på två fält skall fylla någon funktion :-(

Men du kan ha en räknare också. Det är ju inget problem. En rad = ID = en kombination av nr och namn.

Niklas, jag måste ju vänta tills den riktiga problemställningen träder fram klart och tydligt ;)

Och som det sägs, det är inga problem att ha en räknare för att underlätta sammankoppling av tabeller, även om det finns medlemmar som skulle duga som PK tillsammans.

Jag brukar ha en räknare i de flesta tabeller, men i tabeller som används för många till många relationer sätter jag primärnyckeln till de två fält som behövs, eftersom det är det mest naturliga.

Men bara för att det finns två eller flera kandidater som tillsammans skapar en unik rad är det inte sagt att de är de bästa att använda som PK. Till exempel skulle man i varje tabell kunna ha alla fält hörande till PK, men det skulle bli ett helvete att skriva SQL satserna.

Jag tycker att två, absolut maximalt tre, fält kan agera primärnyckel, annars skapar man en räknare och sätter de fält som tillsammans ska vara unika ihop med en constraint.

Sen är det ju prestandafunderingar kring detta också, är till exempel ingen idé att köra primärnycklar på teckensträngar då de i många fall drar ner prestandan och gör index mycket stora, helt i onödan.

Det jag menade var iofs tidsskillnaden mellan båda våra svar... =)

Men jag håller med om vad du säger i sak.

Jaha, noterade inte att du var hela 1 sekund före med att säga samma sak som jag =)
Det kan inte bli så mycket mer tight med tid än det ;)