Übersicht<br />Folien zum Thema Datenbank-Design als Ergänzung zum Kurs „Introductionto Computer Science“der Oracle Academ...
Daten und Informationen<br />Daten<br />Informationen<br />„Rohmaterial“<br />Muss erst ausgewertet werden um daraus Entsc...
Was ist eine Datenbank?<br />Eine Datenbank ist eine Software, in der Daten strukturiert gespeichert werden können.<br />D...
Der Entwicklungsprozess<br />Informationsbedarf definieren<br />Entwurf eines DB-Konzepts(ER-Modell)<br />Datenbankdesign(...
Konzept versus phys. Modell<br />Konzept<br />Physisches Modell<br />Analyse und Planung der DB<br />Rein an den Bedürfnis...
Entity und Instance<br />Instance<br />Entity<br />Eine Name für ähnliche Dinge<br />meist ein Hauptwort<br />Ein konkrete...
 non tangible
 Events</li></li></ul><li>Attribut<br />… beschreibt eine Entity genauer(Qualität, Quantität etc.)<br />Wichtig!<br /><ul>...
Immer nur ein „Wert“.
Manche Attribute müssen eine Wert haben, andere wieder nicht.</li></ul>Unterscheidung:<br /><ul><li> volatile
 non volatile</li></li></ul><li>Identifier (UID)<br />	Jede Instanz wird durch ein Attribut eindeutig gekennzeichnet <br /...
Entity Relationship Model<br />… ist eine Beschreibung aller Entities und Attribute sowie den Beziehungen (Relationship) z...
Ziele eines ER-Modells<br />Alle benötigten Informationen sollen aufgenommen werden.<br />Jede Information sollte nur einm...
Ü: Entities, Instances, Attributes and Identifiers<br />
Ü: Entities, Instances, Attributes and Identifiers<br />
ER Diagrammkonventionen<br />KUNDE<br /># Kunden_id<br />* Vorname<br />* Nachname<br />o Emailadresse<br />…<br />MAHNUNG...
Speaking ERDish<br />
Speaking ERDish<br />
Speaking ERDish<br />
Übungsbeispiele<br />
Übungsbeispiele<br />
Übungsbeispiele<br />
Übungsbeispiele<br />Zeichne ein ER-Diagramm zu folgendem Fall und schreibe die Beziehung in „ERDish“ an.<br />
Übungsbeispiele<br />Zeichne ein ER-Diagramm zu folgendem Fall und schreibe die Beziehung in „ERDish“ an.<br />
Matrixdiagramme<br />Feststellen, welche Beziehung zwischen unterschiedlichen Entities vorhanden ist.<br /> Übersicht bei...
Matrixdiagramme<br />Beinhaltet NICHT<br /><ul><li> Optionalität
 Kardinalität</li></ul>Enthält aber den Namen der Beziehung<br />
Übungsbeispiel<br />Erstelle zu folgendem ER Diagramm ein Matrixdiagramm<br />
Supertypes & Subtypes<br />Eine Enity kann in „Subtypen“ strukturiert werden.<br />Der Subtyp erbt<br /><ul><li> alle Attr...
 alle Beziehung des Supertyps</li></ul>Der Subtyp hat natürlich <br /><ul><li> eigene Attribute
 und kann eigene Beziehungen haben</li></li></ul><li>Supertypes & Subtypes<br />Beispiel einer Enity mit Subtypen sowie Be...
Supertypes & Subtypes<br />„Design“-Hinweise für Supertypen<br />Exhaustative („erschöpfend“)<br />Jede Instanz des Supert...
Übung<br />
Business Roles<br />Stuctural Roles (Beschreiben die Informationstypen und Beziehungen)<br />„Alle Bestellungen müssen von...
Business Roles<br />ProceduralRoles(Beschreiben die Arbeitsabläufe und Geschäftsprozesse)<br />„Eine Bestellung über 5.000...
Relationship Transferability<br />Optionality: Kann oder Muss eine Beziehung vorhanden sein.<br />Cardinality: Wird eine B...
Relationship Transferability<br />Nicht transferierbare Beziehungen werden mit einer Raute („Diamond“) gekennzeichnet<br /...
Übungsbeispiele<br />
Beziehungstypen<br />1:N Beziehung<br />
Beziehungstypen<br />M:N Beziehungen<br />Meistens werden M:N Beziehung in zwei 1:N Beziehungen aufgelöst. <br />Dies ist ...
Beziehungstypen<br />1:1 Beziehungen<br />Könnte man dieses Beispiel auch anders modellieren?<br />
Redundante Beziehungen<br />Zwischen zwei Entities können mehrere Beziehungen bestehen.<br />Die Benennung der Beziehung z...
M:N Beziehungen auflösen<br />M:N Beziehungen können in zwei<br />1:N Beziehungen aufgelöst werden.<br />Die neu entstande...
Barred Relationships<br />Wird bei einer Intersection Entity der UID (Unique Identifier) als Teil des Schlüssels übernomme...
Übungsbeispiel<br />
CRUD Analyse<br />Create, Retrieve, Update, Delete<br />Die CRUD Analyse eignet sich dazu ein ER-Diagramm zu validieren. D...
Composite UID<br />zusammengesetzter Schlüssel<br />dann notwendig,<br />wenn ein Attribut<br />nicht reicht<br />
Composite UID & Barred Rel.<br />Oft wird aus der übergeordneten Entity der Primary UID als Teil des Schlüssels übernommen...
Artificial  UID<br />Oft existiert kein passendes Attribut für einen UID. In diesem Fall muss ein „künstlicher“ Schlüssel ...
Candidate UID<br />Manchmal existieren mehrere Attribute, welche sich für einen UID eigenen. In diesem Fall soll der „best...
Erste Normalform<br />„Es gibt keine Attribute mit wiederholten Werten.“<br />-<br />
Übungen<br />Wo ist die erst NF nicht erfüllt?<br />
Übungen<br />Wo ist die erst NF nicht erfüllt?<br />
Zweite Normalform<br />Was ist bei diesem Beispiel mit einem Composite UID problematisch?<br />Was passiert wenn ein Liefe...
Zweite Normalform<br />„Alle Attribute müssen vom gesamten Schlüssel logisch abhängig sein.“<br />Bank location ist nicht ...
Übung<br />
Übung<br />
Dritte Normalform<br />Was ist bei diesem Beispiel problematisch?<br />Sollen die Informationen über Name und Anschrift de...
Dritte Normalform<br />„Kein Attribut darf von einem anderen Attribut (das nicht zum Schlüssel gehört) funktional abhängig...
Übungen<br />
Constraints<br />Alle Regeln, Bedingungen und Einschränkungen werden „Constraints“ genannt.<br />Diese können sich auf Att...
Arcs<br />Mit Arcs können „ODER“ Beziehungen dargestellt werden.<br />zB eine Instanz von Billboard kann entweder eine Bez...
Übung<br />A show ticket is purchased from an agent, the box office, or the Internet. A ticket has a description, an event...
Hierarchische Beziehungen<br />Für Organisationsdiagramme,<br />Gebäudestrukturen, Stammbäume etc.<br />
Rekursive Beziehungen<br />Entities können auch Beziehungen zu sich selbst haben.<br />zB.: Mitarbeiter, die auch gleichze...
Vergleich<br />Manchmal können sowohl rekursive als auch hierarchische Beziehungen verwendet werden.<br />Versuche die Vor...
Übung<br />Develop two ER diagrams to represent the following situation. Develop one using a hierarchical structure and on...
Historische Daten<br />Wenn sich Daten im Lauf der Zeit ändern (zB Gehalt, Preis etc.) ist es oft sinnvoll die Historie zu...
Übung<br />“You know, we really need to keep a history of all our rentals. Each time a customer rents a DVD, we would like...
Veränderungen : Zeit<br />Beispiel: Ein Bierlieferant möchte bei jedem Verkauf auch die Tagestemperatur erfassen:<br />Die...
Veränderungen: Zeit<br />Beispiel: Für eine Ausstellung sollen Freiwillige in Schichten an einem Stand stehen.<br />
Übung<br />Each police officer may issue speeding tickets to motorists in an assigned area. Originally, the attribute date...
Veränderungen: Preis<br />Häufig (eigentlich fast immer) sind auch Preise veränderbar.<br />Und sehr oft muss man wissen, ...
Übung<br />“Comic-book collectors need to know the price history of different types of comics. This helps them decide what...
Das Relationenmodell<br />
Primärschlüssel<br /><ul><li> Kann zusammengesetzt sein
 Darf nicht „NULL“ sein</li></li></ul><li>Fremdschlüssel<br />Wenn der Fremdschlüssel selbst Teil des Primärschlüssels ist...
Constraints<br />
Vom ERD zum Relationenmodell<br />Bsp.:<br />Wichtig: Es müssen diverse Regeln beachtet werden!<br />Bitte diese in Sectio...
Einführung in SQL<br />SQL = Structured Query Language<br />Datenbanksprache für „alle“ Aufgaben<br />zB.: Tabellen anlege...
Einige Befehle<br />DESCRIBE demo;<br />SELECT * FROM demo;<br />INSERT INTO demotable VALUES (10,‘A‘,20);<br />ALTER TABL...
Kategorien von SQL<br />DML (Data manipulationlanguage)zB.: INSERT, UPDATE, DELETE<br />DDL (Data definitionlanguage)zB.: ...
Übung<br />Und nun selbständig:<br />Enter two or three rows of data with a new type (CLASSICAL, NEW AGE, JAZZ – your choi...
Aufbau<br />Klausel (clause)<br />Schlüsselwort <br />(keyword)<br />Anweisung (statement)<br />Ende der der Anweisung<br ...
Select Anweisung<br />Bsp.:<br />SELECT nn, vn<br />FROM kunden<br />WHERE id=3;<br />
Select Anweisung<br />
Join<br />
 Spalten auswählen<br />SELECT id, title, <br />duration, artist,  <br />type_code<br />FROM d_songs;<br />oder<br />Alle ...
Berechnungen<br />+, -, * /		Klammern können verwendet werden<br />SELECT last_name, salary, <br />salary + 300<br />FROM ...
NULL-Werte<br />NULL = „NIX“<br />NULL * irgendwas = „NIX“<br />NULL + irgendwas = „NIX“ usw.<br />Achtung:  	3/NULL „NIX...
ALIAS<br />Ausgabefelder können anders benannt werden:<br />SELECT id AS id_nummer FROM demo;<br />SELECT id AS “ID Nummer...
Übung:<br />„Zum Aufwärmen“<br />
„Concatenation“<br />Mit || können Ausdrücke verknüpft werden:<br />zB.:<br />SELECT last_name || ‘  ‘ || first_name AS fu...
DISTINCT<br />Mit DISTINCT können Duplikate aus der Ergebnismenge entfernt werden.<br />zB.:<br />SELECT DISTINCT departme...
Übung:<br />„Einfache SELECT Anweisungen“<br />
WHERE…<br />Mit einer „WHERE“ Klausel kann die Ergebnissmenge eingeschränkt werden.<br />zB.:<br />SELECT * FROM employees...
Nächste SlideShare
Wird geladen in …5
×

Database Design - Introduction

3.985 Aufrufe

Veröffentlicht am

An introduction to Database Design (Based on the contents of OracleAcedmy's curriculum)

Veröffentlicht in: Bildung
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.985
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
125
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Database Design - Introduction

  1. 1. Übersicht<br />Folien zum Thema Datenbank-Design als Ergänzung zum Kurs „Introductionto Computer Science“der Oracle Academy.<br />Abbildungen und Übungen stammen teilweise aus dem Trainingsprogramm der Oracle Academy. (https://academy.oracle.com/)<br />
  2. 2. Daten und Informationen<br />Daten<br />Informationen<br />„Rohmaterial“<br />Muss erst ausgewertet werden um daraus Entscheidungen zu treffen.<br />„Wissen“<br />Daten mit bestimmter Bedeutung und Funktion<br />
  3. 3. Was ist eine Datenbank?<br />Eine Datenbank ist eine Software, in der Daten strukturiert gespeichert werden können.<br />Das Hauptaugenmerk liegt darauf, die Daten nach unterschiedlichen Kriterien auswerten zu können.<br />So werden aus DatenInformation erzeugt.<br />Beispiele…<br />
  4. 4. Der Entwicklungsprozess<br />Informationsbedarf definieren<br />Entwurf eines DB-Konzepts(ER-Modell)<br />Datenbankdesign(Relationales Modell entwerfen)<br />Datenbank erstellen bzw. programmieren(SQL)<br />
  5. 5. Konzept versus phys. Modell<br />Konzept<br />Physisches Modell<br />Analyse und Planung der DB<br />Rein an den Bedürfnissen des Unternehmens orientiert<br />Kümmert sich nicht um die Implementierung (= wie und womit „programmiert“)<br /> ER-Modell<br />Konkrete Umsetzung des Konzepts<br />Orientiert sich am technisch machbaren und der zugrundeliegenden Software<br />
  6. 6. Entity und Instance<br />Instance<br />Entity<br />Eine Name für ähnliche Dinge<br />meist ein Hauptwort<br />Ein konkretes „Ding“<br />Unterscheidung:<br /><ul><li>tangible
  7. 7. non tangible
  8. 8. Events</li></li></ul><li>Attribut<br />… beschreibt eine Entity genauer(Qualität, Quantität etc.)<br />Wichtig!<br /><ul><li>Konkrete „Werte“ nur bei Instanzen.
  9. 9. Immer nur ein „Wert“.
  10. 10. Manche Attribute müssen eine Wert haben, andere wieder nicht.</li></ul>Unterscheidung:<br /><ul><li> volatile
  11. 11. non volatile</li></li></ul><li>Identifier (UID)<br /> Jede Instanz wird durch ein Attribut eindeutig gekennzeichnet <br />(UID – unique identifier)<br /> kann auch eine Kombination mehrerer Attribute sein.<br />Beispiele…<br />
  12. 12. Entity Relationship Model<br />… ist eine Beschreibung aller Entities und Attribute sowie den Beziehungen (Relationship) zwischen den Entities.<br />… Aus dem ER-Modell (Konzept) kann später ein konkretes phys. Modell entwickelt werden.<br />
  13. 13. Ziele eines ER-Modells<br />Alle benötigten Informationen sollen aufgenommen werden.<br />Jede Information sollte nur einmal im Modell vorkommen.<br />Es sollen keine Informationen vorkommen, die aus anderen Informationen ermittelt werden können.<br />Jede Information soll dort angesiedelt werden, an der man sie logischerweise auch suchen würde.<br />
  14. 14. Ü: Entities, Instances, Attributes and Identifiers<br />
  15. 15. Ü: Entities, Instances, Attributes and Identifiers<br />
  16. 16. ER Diagrammkonventionen<br />KUNDE<br /># Kunden_id<br />* Vorname<br />* Nachname<br />o Emailadresse<br />…<br />MAHNUNG<br /># Mahnung_id<br />* Datum<br />o Anmerkung<br />….<br />bekommt<br />bezieht sich auf<br />Kardinalität (Single Toe/Crow Foot)<br />Optionalität (solid/dotted)<br />Enity (Capital Letters)<br />Attribute (#,*,o)<br />
  17. 17. Speaking ERDish<br />
  18. 18. Speaking ERDish<br />
  19. 19. Speaking ERDish<br />
  20. 20. Übungsbeispiele<br />
  21. 21. Übungsbeispiele<br />
  22. 22. Übungsbeispiele<br />
  23. 23. Übungsbeispiele<br />Zeichne ein ER-Diagramm zu folgendem Fall und schreibe die Beziehung in „ERDish“ an.<br />
  24. 24. Übungsbeispiele<br />Zeichne ein ER-Diagramm zu folgendem Fall und schreibe die Beziehung in „ERDish“ an.<br />
  25. 25. Matrixdiagramme<br />Feststellen, welche Beziehung zwischen unterschiedlichen Entities vorhanden ist.<br /> Übersicht bei vielen Entities behalten<br />
  26. 26. Matrixdiagramme<br />Beinhaltet NICHT<br /><ul><li> Optionalität
  27. 27. Kardinalität</li></ul>Enthält aber den Namen der Beziehung<br />
  28. 28. Übungsbeispiel<br />Erstelle zu folgendem ER Diagramm ein Matrixdiagramm<br />
  29. 29. Supertypes & Subtypes<br />Eine Enity kann in „Subtypen“ strukturiert werden.<br />Der Subtyp erbt<br /><ul><li> alle Attribute des Supertyps
  30. 30. alle Beziehung des Supertyps</li></ul>Der Subtyp hat natürlich <br /><ul><li> eigene Attribute
  31. 31. und kann eigene Beziehungen haben</li></li></ul><li>Supertypes & Subtypes<br />Beispiel einer Enity mit Subtypen sowie Beziehungen zum Supertypen als auch untergeordneten Subtypen<br />
  32. 32. Supertypes & Subtypes<br />„Design“-Hinweise für Supertypen<br />Exhaustative („erschöpfend“)<br />Jede Instanz des Supertyps ist auch eine Instanz eines Subtyps<br />MutuallyExclusive („wechselseitig ausschließend)<br />Jede Instanz des Supertyps ist eine Instanz von genau einem Subtyps<br />OTHER<br />
  33. 33. Übung<br />
  34. 34. Business Roles<br />Stuctural Roles (Beschreiben die Informationstypen und Beziehungen)<br />„Alle Bestellungen müssen von einem Mitarbeiter bearbeitet werden. Es gibt keine Selbstbedienung.“<br />
  35. 35. Business Roles<br />ProceduralRoles(Beschreiben die Arbeitsabläufe und Geschäftsprozesse)<br />„Eine Bestellung über 5.000 Euro muss vom Vorgesetzten abgezeichnet werden bevor sie an die Versandabteilung weitergeleitet wird.“<br />
  36. 36. Relationship Transferability<br />Optionality: Kann oder Muss eine Beziehung vorhanden sein.<br />Cardinality: Wird eine Beziehung zu einer Instanz oder zu mehreren Instanzen gemacht.<br />Transferability: Kann die Beziehung zwischen zwei Entities verändert werden.<br />
  37. 37. Relationship Transferability<br />Nicht transferierbare Beziehungen werden mit einer Raute („Diamond“) gekennzeichnet<br />Beispiele:<br />Ein Student kann die Studiengruppe wechseln.<br />Eine Rechnung ist auf eine Person bezogen. Ist sie falsch muss sie storniert und neu ausgestellt werden.<br />
  38. 38. Übungsbeispiele<br />
  39. 39. Beziehungstypen<br />1:N Beziehung<br />
  40. 40. Beziehungstypen<br />M:N Beziehungen<br />Meistens werden M:N Beziehung in zwei 1:N Beziehungen aufgelöst. <br />Dies ist jedoch beim Design nicht zwingend notwendig!Viele Datenbanken (physische Umsetzung des Konzepts) können aber nicht mit <br />M:N Beziehungen arbeiten<br />
  41. 41. Beziehungstypen<br />1:1 Beziehungen<br />Könnte man dieses Beispiel auch anders modellieren?<br />
  42. 42. Redundante Beziehungen<br />Zwischen zwei Entities können mehrere Beziehungen bestehen.<br />Die Benennung der Beziehung zeigt ob die Beziehung redundant ist oder tatsächlich zwei unterschiedliche Beziehungen vorhanden sind.<br />
  43. 43. M:N Beziehungen auflösen<br />M:N Beziehungen können in zwei<br />1:N Beziehungen aufgelöst werden.<br />Die neu entstandene Entity wird Intersection Entity genannt.<br />Dies ist aber im Design nur für die bessere<br />Verständlichkeit notwendig.<br />Bei der physischen Umsetzung in ein Daten-<br />Modell muss meist zwingendend eine <br />Auflösung erfolgen.<br />
  44. 44. Barred Relationships<br />Wird bei einer Intersection Entity der UID (Unique Identifier) als Teil des Schlüssels übernommen, dann wird dies durch Striche („Bar“) dargestellt.<br />Damit wird angezeigt, dass die UIDs als Attribute in der Intersection Entity übernommen werden.<br />
  45. 45. Übungsbeispiel<br />
  46. 46. CRUD Analyse<br />Create, Retrieve, Update, Delete<br />Die CRUD Analyse eignet sich dazu ein ER-Diagramm zu validieren. Dazu werden die Gespräche mit den Kunden auf Verben untersucht, die sich inhaltlich auf „Erzeugen“, „Abfragen“, „Ändern“ und „Löschen“ beziehen.<br />
  47. 47. Composite UID<br />zusammengesetzter Schlüssel<br />dann notwendig,<br />wenn ein Attribut<br />nicht reicht<br />
  48. 48. Composite UID & Barred Rel.<br />Oft wird aus der übergeordneten Entity der Primary UID als Teil des Schlüssels übernommen<br />UID Account: #BankNumber + #AccountNumber<br />
  49. 49. Artificial UID<br />Oft existiert kein passendes Attribut für einen UID. In diesem Fall muss ein „künstlicher“ Schlüssel modelliert werden.<br />
  50. 50. Candidate UID<br />Manchmal existieren mehrere Attribute, welche sich für einen UID eigenen. In diesem Fall soll der „beste“ UID ausgewählt werden.<br />
  51. 51. Erste Normalform<br />„Es gibt keine Attribute mit wiederholten Werten.“<br />-<br />
  52. 52. Übungen<br />Wo ist die erst NF nicht erfüllt?<br />
  53. 53. Übungen<br />Wo ist die erst NF nicht erfüllt?<br />
  54. 54. Zweite Normalform<br />Was ist bei diesem Beispiel mit einem Composite UID problematisch?<br />Was passiert wenn ein Lieferant 100 Produkte anbietet und sein Name geändert werden muss?<br />
  55. 55. Zweite Normalform<br />„Alle Attribute müssen vom gesamten Schlüssel logisch abhängig sein.“<br />Bank location ist nicht von AccountNumber und BankNumber sondern nur von der BankNumber abhängig und muss in der Entity Bank gespeichert werden.<br />
  56. 56. Übung<br />
  57. 57. Übung<br />
  58. 58. Dritte Normalform<br />Was ist bei diesem Beispiel problematisch?<br />Sollen die Informationen über Name und Anschrift des Geschäfts wirklich in der Entity CD gespeichert werden?<br />
  59. 59. Dritte Normalform<br />„Kein Attribut darf von einem anderen Attribut (das nicht zum Schlüssel gehört) funktional abhängig sein.“<br />
  60. 60. Übungen<br />
  61. 61. Constraints<br />Alle Regeln, Bedingungen und Einschränkungen werden „Constraints“ genannt.<br />Diese können sich auf Attribute, Entitäten und Beziehungen beziehen.<br />zB.: Eine Bestellung muss von einem Mitarbeiter gemacht werden – keine Selbstbedienung (Constraint bei Beziehung)<br />
  62. 62. Arcs<br />Mit Arcs können „ODER“ Beziehungen dargestellt werden.<br />zB eine Instanz von Billboard kann entweder eine Beziehung zu Movie, ProductAdvertisement oder Public Announcement haben.<br />Arcs und Subtypes können oft alternativ verwendet werden.<br />Kreise kennzeichnen die betroffenen Beziehungen!<br />
  63. 63. Übung<br />A show ticket is purchased from an agent, the box office, or the Internet. A ticket has a description, an event, a date and a price. An agent has a name and a phone number. The box office has an address and a phone number. The Internet has a URL address. <br />Draw the entities and represent the exclusive relationship. <br />
  64. 64. Hierarchische Beziehungen<br />Für Organisationsdiagramme,<br />Gebäudestrukturen, Stammbäume etc.<br />
  65. 65. Rekursive Beziehungen<br />Entities können auch Beziehungen zu sich selbst haben.<br />zB.: Mitarbeiter, die auch gleichzeitig Vorgesetzte sein können.<br />
  66. 66. Vergleich<br />Manchmal können sowohl rekursive als auch hierarchische Beziehungen verwendet werden.<br />Versuche die Vor- und Nachteile beider Lösungen herauszuarbeiten!<br />
  67. 67. Übung<br />Develop two ER diagrams to represent the following situation. Develop one using a hierarchical structure and one using a recursive structure. <br />“Our company sells products throughout the United States. So we’ve divided the U.S. into four major sales regions: the Northern, Eastern, Southern, and Western regions. Each sales region has a unique region code. Each sales region is then divided into sales districts. For example, the Western region is divided into the Rocky Mountain, Northwest, Pacific Coast, and Pacific districts. Each district has a unique district code. Each district is made up of sales territories. The Rocky Mountain district is composed of three territories: Wyoming-Montana, Colorado, and Utah-New Mexico. The Northwest district is made up of two territories: the Washington and Oregon-Idaho territories. The Pacific Coast district is composed of two territories: the California and Nevada territories. The Pacific District includes the Hawaii territory and the Alaska territory. Each territory has a unique territory code. <br />Then each sales territory is broken down into sales areas. For example, Colorado is made up of two sales areas: the Front Range and the Western Slope sales areas. Each sales area has a unique sales-area code. <br />Each salesperson is responsible for one or more sales areas and has a specific sales quota. We also have sales managers who are responsible for one or more sales districts, and sales directors who are responsible for one or more sales <br />Oracle Academy 1 Database Design Copyright © 2008, Oracle. All rights reserved. Oracle Academy 2 Database Design Copyright © 2008, Oracle. All rights reserved. <br />regions. Each sales manager is responsible for the territories with his/her districts. We don’t overlap our employees’ responsibilities. Each sales area is always the responsibility of a single salesperson, and our managers' and directors' responsibilities don’t overlap. Sometimes our salespersons, managers, and directors will have special assignments and will not be responsible for sales. We identify all our sales personnel by their employee IDs.” <br />
  68. 68. Historische Daten<br />Wenn sich Daten im Lauf der Zeit ändern (zB Gehalt, Preis etc.) ist es oft sinnvoll die Historie zu speichern.<br />
  69. 69. Übung<br />“You know, we really need to keep a history of all our rentals. Each time a customer rents a DVD, we would like to keep the rental date/time and the return date/time. All our DVDs are due back the next day, so we don’t need to keep a due date. Keeping this rental history will allow us to analyze the pattern of our rentals. We will be able to determine how many DVDs each customer rents and how many times a customer has returned a DVD late. We will also know how many times a particular DVD has been used and will then know when to retire each DVD. We will also be able to analyze our customers’ movie preferences.”<br />Ändere das Modell rechts sodass die oben dargestellten Anforderungen erfüllt sind.! <br />
  70. 70. Veränderungen : Zeit<br />Beispiel: Ein Bierlieferant möchte bei jedem Verkauf auch die Tagestemperatur erfassen:<br />Die 3. NF ist verletzt!<br />Daher muss anders modelliert werden.<br />
  71. 71. Veränderungen: Zeit<br />Beispiel: Für eine Ausstellung sollen Freiwillige in Schichten an einem Stand stehen.<br />
  72. 72. Übung<br />Each police officer may issue speeding tickets to motorists in an assigned area. Originally, the attribute date was modeled as part of the SPEEDING TICKET entity. However, the city police department wants to see if there is a relationship between weather and the frequency of speeding tickets -- do people drive faster on nice sunny days? Are there more tickets in hot weather or cool weather?<br />Wie kannst du die Problemstellung lösen?<br />
  73. 73. Veränderungen: Preis<br />Häufig (eigentlich fast immer) sind auch Preise veränderbar.<br />Und sehr oft muss man wissen, wie viel ein Produkt an einem bestimmten Tag gekostet hat.<br />
  74. 74. Übung<br />“Comic-book collectors need to know the price history of different types of comics. This helps them decide what to purchase/collect and how much to sell their collection for. “<br />Zeichne ein ER-Modell (2 oder 3 Entities) für diese Problemstellung.<br />
  75. 75. Das Relationenmodell<br />
  76. 76. Primärschlüssel<br /><ul><li> Kann zusammengesetzt sein
  77. 77. Darf nicht „NULL“ sein</li></li></ul><li>Fremdschlüssel<br />Wenn der Fremdschlüssel selbst Teil des Primärschlüssels ist, dann darf dieser nicht NULL sein!<br />
  78. 78. Constraints<br />
  79. 79. Vom ERD zum Relationenmodell<br />Bsp.:<br />Wichtig: Es müssen diverse Regeln beachtet werden!<br />Bitte diese in Section 11 genau durcharbeiten!<br />„Relationship Mapping“<br />
  80. 80. Einführung in SQL<br />SQL = Structured Query Language<br />Datenbanksprache für „alle“ Aufgaben<br />zB.: Tabellen anlegen, Daten hinzufügen und löschen, Tabellen auswerten.<br />
  81. 81. Einige Befehle<br />DESCRIBE demo;<br />SELECT * FROM demo;<br />INSERT INTO demotable VALUES (10,‘A‘,20);<br />ALTER TABLE demo ADD (plz CHAR(6));<br />ALTER TABLE demo DROP COLUMN plz;<br />DELETE FROM TABLE demo WHERE id=5;<br />… und viele viele weitere mehr….<br />
  82. 82. Kategorien von SQL<br />DML (Data manipulationlanguage)zB.: INSERT, UPDATE, DELETE<br />DDL (Data definitionlanguage)zB.: CREATE, ALTER, DROP<br />TCL (Transaction controllanguage)zB.: COMMIT, ROLLBACK<br />DCL (Data controllanguage)zB.: GRANT, REVOKE<br />
  83. 83. Übung<br />Und nun selbständig:<br />Enter two or three rows of data with a new type (CLASSICAL, NEW AGE, JAZZ – your choice). Then retrieve only the rows of data with this new music type. <br />Add at least five new rows and two new columns to the MUSIC table. If you make mistakes, use the DELETE and ALTER commands to correct them. <br />Übung:<br />„BASIC SQL COMMANDS“<br />
  84. 84. Aufbau<br />Klausel (clause)<br />Schlüsselwort <br />(keyword)<br />Anweisung (statement)<br />Ende der der Anweisung<br />mittels ;<br />
  85. 85. Select Anweisung<br />Bsp.:<br />SELECT nn, vn<br />FROM kunden<br />WHERE id=3;<br />
  86. 86. Select Anweisung<br />
  87. 87. Join<br />
  88. 88. Spalten auswählen<br />SELECT id, title, <br />duration, artist, <br />type_code<br />FROM d_songs;<br />oder<br />Alle Spalten<br />SELECT * FROM d_songs;<br />SELECT id, title, <br />FROM d_songs;<br />Bestimmte Spalten<br />
  89. 89. Berechnungen<br />+, -, * / Klammern können verwendet werden<br />SELECT last_name, salary, <br />salary + 300<br />FROM employees;<br />Rangfolge der Operatoren („Precedence“) beachten:<br />MyDearAuntSally<br />
  90. 90. NULL-Werte<br />NULL = „NIX“<br />NULL * irgendwas = „NIX“<br />NULL + irgendwas = „NIX“ usw.<br />Achtung: 3/NULL „NIX“<br /> 3/0  Fehler!!!<br />
  91. 91. ALIAS<br />Ausgabefelder können anders benannt werden:<br />SELECT id AS id_nummer FROM demo;<br />SELECT id AS “ID Nummer“ FROM demo;<br />Oder: Bei Leerzeichen, Sonderzeichen<br />und Groß-/Kleinschreibung<br />
  92. 92. Übung:<br />„Zum Aufwärmen“<br />
  93. 93. „Concatenation“<br />Mit || können Ausdrücke verknüpft werden:<br />zB.:<br />SELECT last_name || ‘ ‘ || first_name AS full_name FROM employees;<br />
  94. 94. DISTINCT<br />Mit DISTINCT können Duplikate aus der Ergebnismenge entfernt werden.<br />zB.:<br />SELECT DISTINCT department_id FROM employees;<br />
  95. 95. Übung:<br />„Einfache SELECT Anweisungen“<br />
  96. 96. WHERE…<br />Mit einer „WHERE“ Klausel kann die Ergebnissmenge eingeschränkt werden.<br />zB.:<br />SELECT * FROM employees<br />WHERE id=3;SELECT * FROM employeesWHERE first_name = ‘Huber‘;<br />Logische Operatoren:<br />=<br />><br />>=<br /><<br /><=<br /><> bzw. != oder ^=<br />
  97. 97. WHERE…<br />Weitere Möglichkeiten:<br />… WHERE jahrBETWEEN 2000 AND 2010<br />… WHERE plzIN (4560, 4030, 4600)<br />… WHERE jahr > 2000 ANDjahr < 2010<br />… WHERE plz=4560 ORplz=4030<br />Natürlich gibt es auch ein NOT<br />Bei allen logischen Operatoren ist die<br />Reihenfolge der Berechnung zu berücksichtigen!<br />
  98. 98. WHERE<br />„Unscharfe Suche“ mit Platzhaltern<br />… WHERE last_nameLIKE ‘Ma_r%‘<br />_ genau ein beliebiges Zeichen<br />%  mehrere beliebige Zeichen <br />„Escapesequence“: zB ‘‘<br />
  99. 99. WHERE …<br />Nach Nullwerten suchen…<br />… WHERE last_nameIS NULL<br />Achtung: last_name = NULL <br />ist nicht möglich!<br />
  100. 100. Sortieren<br />… ORDER BY last_name;<br />… ORDER BY first_name DESC;<br />… ORDER BY last_name, first_name DESC;<br />
  101. 101. Multiple RowFunctions<br />AVG<br />COUNT<br />MAX<br />MIN<br />SUM<br />Achtung: Das Ergebnis ist dann<br />eine Zeile!<br />Im Gegensatz dazu dienen Single RowFunctions zur <br />Manipulation von Werten (zBSIN etc.)<br />

×