Voraussetzung .net (da wir sehr tief einsteigen) Programmierung

Voraussetzung
.net (da wir sehr tief einsteigen)
Programmierung
DAO
ADO
Berechtigung
File-Server Architektur
Automatische Aktualisierung der Verknuepfung in Access
Literatur:
Droege:
http://www.amazon.de/exec/obidos/tg/detail/offer-listing/-/3860635301/new?tag2=idealocom
Petkovic:
http://www.amazon.de/Server-2005-Eine-umfassende-Einf%fchrung/dp/3898643670/sr=14/qid=1161412476/ref=sr_1_4/028-5610287-4603722?ie=UTF8&s=books
Trigger und Check Constraints (beziehen sich auf sämtliche Felder)
1. Redundanz
• Die gleichen Daten sind mehrfach gespeichert
• Problem bei grossen Datenmengen (Datawarehouse da auch historische Daten und
Komplettstaende gespeichert werden)
• Stored Procedure wird kompiliert
• Vorteil von DB Mgt Systemen: kann beurteilen da im Hintergrund Statistikdaten
bezgl. Bestimmter Felder geliefert werden. Statistikdaten muessen aktualisiert
werden. Wenn dies nicht passiert, dann geht die Performance nach unten
• SQL Server fuehrt Zaehler mit, der die Anzahl der Aenderungen tracked und je
nach Einstellung fuerht er dann ein Statistikdatenupdate durch.
• Speicherplatz ist in operativen DB’s nicht das Problem nur bei Datawarehouse
• Faktum: Objekt -> Eigenschaft -> Wert
das schwierige an der Definition des Faktors ist das herausfinden von Objekten
• Tipp: Klasse und Eigenschaft zusammengesetzes Wort bilden; Bsp: Auge – Farbe
Person – Augenfarbe
• Vor- und Nachteile von Redundanz (in relationalen DB’s nicht zu vermeiden da
Fremdschluessel in sich ja grundsaetzlich schon redundant sind)
o Vorteil: Performance, Sicherheitsgruenden (Backup)
o Nachteil: 3 Anomalien
 Aenderungsanomalie:
wenn sich bei redundanten Daten ein Datensatz aendert, dann
stimmen diese nicht mehr überein => Widerspruch da man nicht
mehr weiss was richtig ist
 Hinzufuegeanomalie:
entsteht wenn man mit Dummies arbeitet (e.g. Auftraege die noch
nicht konkret da sind aber als Dummy eingetragen werden)
 Loeschanomalie:
wenn der letzte Satz mit redundanten Informationen geloescht wird
sind die Daten definitv weg
• Wo interessiert mich Redundanz gar nicht:
•
•
•
•
o Wenn sich Daten nie aendern (Datawarehouse werden Daten inkrementel
dazu gefuegt)
Bei Operativen DB’s will man immer so aktuell wie nur moeglich zu sein
o Integritaetsregeln welche Aenderungen welche Inkonsistenz nach sich
ziehen
o Aenderungen werden z.B. durch Trigger durchgereicht auf alle Anderen
Datensaetze
Mit Integritaetsregeln verhindern dass Redundanz entsteht
Pragmatische Definition von Redundanz: Redundanz haben wir dann wenn
o eine Aenderung in der Realitaet n-Aenderungen in der DB nach sich ziehen
o zukuenftige Aenderungen
Varianten Stuecklisten:
Kunde: Ort, Strasse, Hausnummer
2. Datenmodellierung
a. Analyse des Informationsbedarfs
Aufzaehlungen und Durchnummerierungen sind ganz schlecht, da immer das
Problem besteht, dass noch ein weiteres Element dazu kommt.
Bsp.:
- Kunde -> Tel1, Tel2, Tel3,...
- Kunde -> TelNr (nur bei suchirrelevanten Feldern)
- Kunde + Telfontabelle (Vorteil: man muss auf Grund der
Anzahl der Elemente keines der Programme aendern)
Left join. Join immer weniger performant als eine Tabelle zu durchsuchen
Bsp. Bibliotheks System:
2 Ueberlegungen:
- auf welche Ebene der Modellierung gehe ich herunter
- wie fasse ich die Klassenobjekte zusammen
Problem bei allen Objekten in einer Kasse ist (siehe Seite 7) dass sehr viele Felder
entstehen und viele dann auch einen NULL wert haben und somit nicht belegt
sind. Zwingend muss eine weiteres Feld „Art“ definiert werden. Auch entseht eine
Unmenge von Methoden, welche alle beginnen werden wie if (Art = = ...
Aufpassen dass nicht zu viele unterschiedliche Objekte in eine Klasse gepackt
werden.
Zweites Extrem ist Um Redundanz auf Metaebene zu Beseitigen fasst man
Instanzobjekte zu Klassenobjekten zusammen (siehe Seite 8)
Klasse: ist ein Objekt mit eigener Identitaet
Objekt: haben Identitaet, Verhalten/ Methoden und Eigenschaften/ Attribute
Klassen- und Instanzobjekte
Instanz: sind Objekte
Unterschied zwischen Identitaet (abgrenzbar von einem anderen Objekt, bleibt
waehrend des ganzen Lebenszyklus erhalten bleibt immer in einer Klasse
vorhanden und kann diese nicht wechseln) und Identifizierbarkeit?
Aus Identifizierbarkeit folgt Identitaet...
Aus Identitaet folgt nicht zwangslaeufig Identifizierbar
Objektidentitaeten werden benoetigt um zu Identifizieren
GUID: wenn 2 Systeme bei Frimenkaeufen dann habe ich die Moeglichkeit die IT
Systeme zusammen zu legen.
b. Objekte: Instanzen und Klassen
c. Objektorientiertes Datenmodell
i. Elemente
ii. Vorgehensweise
iii. Kardinalitaeten
d. Relationales Datenmodell
i. Identitaet ueber Primaerschluessel
ii. 1NF
iii. Beziehungen ueber Fremdschluessel
iv. NM-Beziehungen uber zusaetzliche Zwischentabelle
v. Existentielle Abhaengigkeiten uber Loschweitergabe
vi. Keine Vererbung
3. Normalisierung
Merker fuer Klausur:
Präsenzbücher in Bibliothek...
Modellierungsbeispiel:
-
Buch
Entleiher
Ausleihe
Beschaedigung
ISBN
Fachgebiet
Reservierungen
Autoren
Signatur
NK
Fachgebiet
1M
NK
Buch
NK
NK
Reservierung
1M
1M
Beschaedigung
Titel, Autoren,
ISBN, Signatur
Exemplar
NK
1M
1K
NK
Signatur, Status,
Ausleihe
1M
Person
NK
NK
!!! Instanzen in die Kaesten zeichnen und mit linien verbinden => Kardinalitaeten bilden!!!