Konsistens i forbindelse med relationsdatabaser???

1. at databasen opfylder 3. normalorden
2. at alle foreign-keys peger på en record
3. at Keys er INT32/INT64 eller GUID's
4. at der er indexes på relevante opslagstabeller


3. og 4. er 'good practice'

Hej montago

Tak for dit svar.

Kan det evt. forkortes og skrives mindre teknisk?

Mvh
Moo

Hey igen

hvad mener du med "forkortes" ?


vil du gerne have forklaringer på de forskellige begreber ?

Hvis muligt vil jeg gerne - kort - have forklaret begreberne.

Er punkt 1+2 "must" og 3+4 blot "good practice"?

fysiske konsistent = at database strukturen på disken er valid i forhold til database softwaren

logisk konsistent = at de data som er gemt i databasen ikke modsiger sig selv (det betyder ikke at data er rigtige - det betyder bare at data er enten konsekvent rigtige eller konsekvent forkerte)

to metoder til at sikre den logiske konsistens er:
* normalisering
* referentiel integritets begrænsning

En ikke normaliseret tabel kan f.eks. indeholde:

Navn  Postnr    By
Anders 6000      Kolding
Børge  7100      Vejle
Carl  6000      Fredricia

Den er inkonsistent fordi der er to byer med samme postnummer (og det er ikke København hvor det findes).

Ved normalisering vil man ende op med:

Navn  Postnr
Anders 6000
Børge  7100
Carl  6000

Postnr    By
6000      Kolding
7100      Vejle

eller

Navn  Postnr
Anders 6000
Børge  7100
Carl  6000

Postnr    By
6000      Fredricia
7100      Vejle

Begge er konsistente. Den første er rigtig - den anden er forkert.

Referentiel integritet sikrer at man ikke kan ende op med:

Navn  Postnr
Anders 6000
Børge  7100
Carl  6000
Dora  9999

Postnr    By
6000      Kolding
7100      Vejle

fordi referentiel integritet tillader ikke at man bruger et postnr (9999) i den første tabel som ikke eksisterer i den anden tabel.

Altid at bruge INT og GUID som primary key har ikke noget med konsistens at gøre. Det er ikke engang best practice.

Brug af index har ikke noget med konsistens at gøre (*) men er meget vigtig for god performance.

*) Ikke helt rigtigt. Man kan bruge et unique index til at sikre at en kolonne ikke indeholder duplikat værdier.

Der findes kun 2: Logisk konsistens og data konsistens, fysisk konsistens arbejder man ikke med.

Logisk konsistens, kræver lidt db-viden at forstå, men kort fortalt er databasen opbygget af med små byggeklodser/ blokke, hver tabel indeholder extents og hver extent indeholder nogle pages/ data blocks. Oracle har også noget kaldet et segment som altså indeholder extents. Afhængig af producent/ version mv. kan de varierer i størrelse, Microsoft har 8 pages i en extent osv.

Well.. back til spørgsmålet, når så noget ikke overholder en logisk konsistens betyder det altså at der er gået rod i siderne/ pages (torn pages) og derved kan tabellen blive ubrugelig/ lave uorden i mange ting.
[b]Data konsistens[\b] er nok det som de fleste har kendskab til, altså at der findes en primary key til en foreign key... såre simpelt :)

Indexes, datatyper og normalformer har intet med konsistens at gøre. Man kan selvfølgelig argumentere for at inkonsistens kan optræde hvis, som i fremførte ovenstående eksempel, havde 2 byer med forskelligt postnummer, men samme by ville betyde inkonsistens. Men i bund og grund er det pga. designet at data kan opfører sig sådan! Dvs. sagt på en anden måde, man kan ikke direkte udlede at det er forkert uden at bruge noget menneskelig logik :)

Hvis nu man f.eks. arbejder med SQLServer, så:

http://msdn.microsoft.com/en-us/library/ms176064.aspx

Checks the logical and physical integrity of all the objects in the specified database by ...

PHYSICAL_ONLY

    Limits the checking to the integrity of the physical structure of the page and record headers, the physical structure of B-trees, and the allocation consistency of the database. This check is designed to provide a small overhead check of the physical consistency of the database, but it can also detect torn pages, checksum failures, and common hardware failures that can compromise a user's data.

hmm, ja ser ud til at der skelnes. Det er bare lidt sjovt, hvis man kører DBCC CHECKDB


Msg 824, Level 24, State 2, Line 1

SQL Server detected a logical consistency-based I/O error: torn page
(expected signature: 0xaaaaaaaa; actual signature: 0x56aaaaaa). It occurred
during a read of page (1:9) in database ID 7 at offset 0x00000000012000 in
file 'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ICS.mdf'.
Additional messages in the SQL Server error log or system event log may
provide more detail. This is a severe error condition that threatens
database integrity and must be corrected immediately. Complete a full
database consistency check (DBCC CHECKDB). This error can be caused by many
factors; for more information, see SQL Server Books Online.


Hvilket ikke stemmer med PHYSICAL_ONLY som jo siger check for torn pages etc.

Jeg mener at der er en forkludring imellem logical og physical, forskellen er ihvertfald ikke lige til at udlede.

Hvad mener du Arne?

Jeg mener at det giver mest mening at definere:

fysisk inkonsistens = problemer i database specifikke strukturer

logisk inkonsistens = problemer i generelle strukturer uafhængigt af database

det matcher fysisk og logisk database model.

Hvem skal have points?

Jeg skal ikke have nogle.. jeg kom bare ind fra sidelinien :)

Umiddelbart er det jo et diskussions spørgsmål som ligger meget op til en deling.

Her er et svar fra mig.