thomas m connolly-arkiv

oriktig repetition av information i resultatet av sökning i databas. – Fans orsakas av ogenomtänkt konfiguration av databasen eller ogenomtänkt utformning av sökningen (frågan). – Begreppet fan (engelskt uttal) definierades först 1996 av Thomas M Connolly (länk) och Carolyn Begg (länk) i boken Database systems. Fan är en av två connection traps: den andra kallas för chasm. Felet definierades i förhållande till databaser av typen entity‑relationship, men det uppträder även i andra sammanhang. – Något förenklat exempel: ett företag har anställda och avdelningar. I en databas finns en tabell med företagets alla anställda och en annan tabell med företagets alla avdelningar. Om företaget gör en olyckligt formulerad sökning (med en join) efter anställda kan resultatet bli att varje anställd räknas som anställd i var och en av avdelningarna. Sökningen ”vet” inte att varje anställd tillhör bara en avdelning, eller vilken avdelning det i så fall skulle vara. I stället ”tror” sökningen att den som är anställd på företaget tillhör alla företagets avdelningar. Antalet anställda multipliceras därför i resultatet av sökningen; varje namn förekommer flera gånger. I mer komplicerade fall kan felet vara svårt att upptäcka: man ser bara att resultatet av sökningen inte kan stämma. – Man talar om en cartesisk produkt (cartesian product). Det innebär att i stället för att varje anställd knyts till en, och bara en, avdelning (som i en tabell med två spalter), vilket är det riktiga, så knyts varje anställd till var och en av avdelningarna (som i en flerspaltig tabell med de anställda på x‑axeln och avdelningarna på y‑axeln, eller omvänt, och ett kryss i varje ruta). – Uttrycket fan kommer av fan out, som kan översättas med sprida ut [i solfjäderform]. – För att undvika fans bör man lägga upp databasen (eller sökningen) på ett bättre sätt:

– olämpligt: anställd–(av)–företag–(som har)–avdelningar;
– hellre: företag–(har)–avdelningar–(som har)–anställda.

– Exakt hur man bör göra beror på syftet med databasen. (Observera att en del förklaringar på nätet av chasms i själva verket beskriver fans.)

[databaser] [fel] [ändrad 4 juli 2022]

oönskat bortfall av information vid sökning i databas, orsakad av ogenomtänkt konfiguration av databasen eller ogenomtänkt utformning av sökningen (frågan). – Begreppet chasm definierades först 1996 av Thomas M Connolly (länk) och Carolyn Begg (länk) i boken Database systems. Det är en av två connection traps: den andra kallas för fan. Felet definierades i förhållande till databaser av typen entity‑relationship, men det kan tillämpas även på relationsdatabaser och stjärnscheman. – Ett något förenklat exempel: en skola vill räkna sina datorer. Den har en databas med en lista över klassrummen. I varje klassrum finns det, enligt databasen, noll, en eller flera datorer. Om skolan då gör en sökning som för varje klassrum räknar antalet datorer och adderar dem kan resultatet bli fel – vad händer till exempel med datorn som står i receptionen? Receptionen står nämligen inte med i listan över klassrum. Minst en dator som borde ha kommit med i resultatet av sökningen saknas därför. (Observera att receptionens dator mycket väl kan finnas med i skolans databas, men man hittar den inte om sökningen utgår från klassrummen.) Det är sådana bortfall som kallas för chasms, vilket i det här fallet kan översättas med luckor. I mer komplicerade fall kan felet vara svårt att upptäcka: man ser bara att resultatet av sökningen inte verkar stämma. – För att undvika chasms bör man lägga upp databasen (eller sökningen) på ett bättre sätt: skolan har datorer; för varje dator anges ett klassrum eller en annan lokal. – I andra sammanhang kan chasm översättas med klyfta, bråddjup.

[databaser] [fel] [ändrad 2 maj 2022]