Halihallo Lude
sehr schlau, mit einem Posting gleich zwei Fragesteller zufriednzustellen. (Mein Traum war es immer mit einer Antwort alle jemals gestellten Fragen beantworten zu koennen)
Oh da bist du nicht alleine: Du suchst nach der "Theory of everything" (TOE). Eine
Theorie mit der man alles erklären kann... Einsteinanhänger und Quantentheoretiker sind
schon lange auf der Suche danach :-)
Valid Column Integrity (Welche Daten werden überhaupt unterstützt?)
Da gibt es unter 'MSSQLSrv' die Regeln und die Datentypen.
Ja, eigentlich bei den meisten Datenbanken, die die "basics" können. Es geht hier um
das definieren von CONSTRAINTS bzw. CHECK.
Required Data Integrity (Welche Daten müssen unbedingt vorhanden sein?)
Spielt das auf NULL-Werte an?
Ich glaube nicht nur. Nehmen wir an, dass mehrere Attribute required sind und somit beim
INSERT/UPDATE mit NOT NULL Werten gefüllt werden müssen, so müssten diese natürlich mit
NOT NULL definiert sein, nur haben wir dann das Problem, dass der Defaultwert eben auch
nicht NULL sein darf und somit liesse sich das 'required' nicht mehr ohne CHECK checken,
weil ja jedes nicht gesetzte Attribut mit einem gültigen NOT NULL Wert gefüllt wird und
die Rule nicht verletzt werden würde.
Data validity Integrity (Ist der Datentyp und inhalt OK?)
Validieren gegen ein Schema. Dafuer gibt's XML-Schema.
Glaube nicht, dass damit dies gemeint war :-)
Ich schätze mal, dass _diese_ Integrität von allen RDBMS implizit durch Datentyp-
deklaration beim CREATE erfüllt ist, obwohl auch hier ein Check des Inhaltes zur
vollständigkeit durchgeführt werden müsste. Z.B. wäre die Datenvalidität bei einem
UPDATE test (int_value) VALUES ('123test'); nicht sichergestellt, da '123test' nicht
dem transformierten Integer '123' entspricht.
Entity integrity ( ist der Primärschlüssel wirklich unique?; implizit durch Datenbank gegeben )
.
Ja, Punkt. :-)
Business Rule integrity ( unterstützt der Account überhaupt Funktion A,B,C )
Na, und wo liegt die Geschaeftslogik? - Vielleicht in der umgebenden Programmlogik?
Nun, das möchte man genau verhindern. Stell dir ein Informationssystem von einer
grossen Bank vor. Tausende von Clients, seien dies nun EC-Bankomaten, Filialrechner,
oder der Mainframe selber greifen auf dieselbe Datenbank zu (das ist zwar _nie_ so,
aber dennoch taugt es als Beispiel). Stell dir vor, dass nur ein einziges System ein
Security-Leak hätte und die Business Rules nicht genau umsetzt... Milliardenschäden!
Es geht darum, die Datenintegrität an einem und nur einem Ort sicherzustellen und dieser
Ort ist genau da, wo alles koordiniert wird: Bei der RDBMS selber.
Consistency integrity ( sind die Daten konsistent? z.B. wenn Datum für
letzten Gebrauch gewechselt wurde, muss letzer Check auch geändert werden)
Datenkonsistenz ist dann gegeben, wenn die Information auf genau eine Art und Weise aus dem Datenbestand gewonnen werden kann. (Dr.B.)
Nun, das ist zwar richtig und spielt IMHO auf die Normalformen an, aber oftmals ist
eine Datenbank eben nicht ganz redundanzfrei (zwecks Performance) und dann ist es eben
möglich Daten auf verschiedene weisen aus der DB zu extrahieren und die Konsistenz
dieser redundanten Information muss eben stets gegeben sein (ansonsten wieder Mil-
liardenschäden).
---
Puh, krasse Geschichte mit den Datenbanken :-)
Viele Grüsse
Philipp
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.