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

1. Übersicht Folien zum Thema Datenbank-Design als Ergänzung zum Kurs „Introductionto Computer Science“der Oracle Academy. Abbildungen und Übungen stammen teilweise aus dem Trainingsprogramm der Oracle Academy. (https://academy.oracle.com/)

2. Daten und Informationen Daten Informationen „Rohmaterial“ Muss erst ausgewertet werden um daraus Entscheidungen zu treffen. „Wissen“ Daten mit bestimmter Bedeutung und Funktion

3. Was ist eine Datenbank? Eine Datenbank ist eine Software, in der Daten strukturiert gespeichert werden können. Das Hauptaugenmerk liegt darauf, die Daten nach unterschiedlichen Kriterien auswerten zu können. So werden aus DatenInformation erzeugt. Beispiele…

4. Der Entwicklungsprozess Informationsbedarf definieren Entwurf eines DB-Konzepts(ER-Modell) Datenbankdesign(Relationales Modell entwerfen) Datenbank erstellen bzw. programmieren(SQL)

5. Konzept versus phys. Modell Konzept Physisches Modell Analyse und Planung der DB Rein an den Bedürfnissen des Unternehmens orientiert Kümmert sich nicht um die Implementierung (= wie und womit „programmiert“)  ER-Modell Konkrete Umsetzung des Konzepts Orientiert sich am technisch machbaren und der zugrundeliegenden Software

7. non tangible

9. Immer nur ein „Wert“.

12. Entity Relationship Model … ist eine Beschreibung aller Entities und Attribute sowie den Beziehungen (Relationship) zwischen den Entities. … Aus dem ER-Modell (Konzept) kann später ein konkretes phys. Modell entwickelt werden.

13. Ziele eines ER-Modells Alle benötigten Informationen sollen aufgenommen werden. Jede Information sollte nur einmal im Modell vorkommen. Es sollen keine Informationen vorkommen, die aus anderen Informationen ermittelt werden können. Jede Information soll dort angesiedelt werden, an der man sie logischerweise auch suchen würde.

14. Ü: Entities, Instances, Attributes and Identifiers

15. Ü: Entities, Instances, Attributes and Identifiers

16. ER Diagrammkonventionen KUNDE # Kunden_id * Vorname * Nachname o Emailadresse … MAHNUNG # Mahnung_id * Datum o Anmerkung …. bekommt bezieht sich auf Kardinalität (Single Toe/Crow Foot) Optionalität (solid/dotted) Enity (Capital Letters) Attribute (#,*,o)

17. Speaking ERDish

18. Speaking ERDish

19. Speaking ERDish

20. Übungsbeispiele

21. Übungsbeispiele

22. Übungsbeispiele

23. Übungsbeispiele Zeichne ein ER-Diagramm zu folgendem Fall und schreibe die Beziehung in „ERDish“ an.

24. Übungsbeispiele Zeichne ein ER-Diagramm zu folgendem Fall und schreibe die Beziehung in „ERDish“ an.

25. Matrixdiagramme Feststellen, welche Beziehung zwischen unterschiedlichen Entities vorhanden ist.  Übersicht bei vielen Entities behalten

27. KardinalitätEnthält aber den Namen der Beziehung

28. Übungsbeispiel Erstelle zu folgendem ER Diagramm ein Matrixdiagramm

32. Supertypes & Subtypes „Design“-Hinweise für Supertypen Exhaustative („erschöpfend“) Jede Instanz des Supertyps ist auch eine Instanz eines Subtyps MutuallyExclusive („wechselseitig ausschließend) Jede Instanz des Supertyps ist eine Instanz von genau einem Subtyps OTHER

33. Übung

34. Business Roles Stuctural Roles (Beschreiben die Informationstypen und Beziehungen) „Alle Bestellungen müssen von einem Mitarbeiter bearbeitet werden. Es gibt keine Selbstbedienung.“

35. Business Roles ProceduralRoles(Beschreiben die Arbeitsabläufe und Geschäftsprozesse) „Eine Bestellung über 5.000 Euro muss vom Vorgesetzten abgezeichnet werden bevor sie an die Versandabteilung weitergeleitet wird.“

36. Relationship Transferability Optionality: Kann oder Muss eine Beziehung vorhanden sein. Cardinality: Wird eine Beziehung zu einer Instanz oder zu mehreren Instanzen gemacht. Transferability: Kann die Beziehung zwischen zwei Entities verändert werden.

37. Relationship Transferability Nicht transferierbare Beziehungen werden mit einer Raute („Diamond“) gekennzeichnet Beispiele: Ein Student kann die Studiengruppe wechseln. Eine Rechnung ist auf eine Person bezogen. Ist sie falsch muss sie storniert und neu ausgestellt werden.

38. Übungsbeispiele

39. Beziehungstypen 1:N Beziehung

40. Beziehungstypen M:N Beziehungen Meistens werden M:N Beziehung in zwei 1:N Beziehungen aufgelöst. Dies ist jedoch beim Design nicht zwingend notwendig!Viele Datenbanken (physische Umsetzung des Konzepts) können aber nicht mit M:N Beziehungen arbeiten

41. Beziehungstypen 1:1 Beziehungen Könnte man dieses Beispiel auch anders modellieren?

42. Redundante Beziehungen Zwischen zwei Entities können mehrere Beziehungen bestehen. Die Benennung der Beziehung zeigt ob die Beziehung redundant ist oder tatsächlich zwei unterschiedliche Beziehungen vorhanden sind.

43. M:N Beziehungen auflösen M:N Beziehungen können in zwei 1:N Beziehungen aufgelöst werden. Die neu entstandene Entity wird Intersection Entity genannt. Dies ist aber im Design nur für die bessere Verständlichkeit notwendig. Bei der physischen Umsetzung in ein Daten- Modell muss meist zwingendend eine Auflösung erfolgen.

44. Barred Relationships Wird bei einer Intersection Entity der UID (Unique Identifier) als Teil des Schlüssels übernommen, dann wird dies durch Striche („Bar“) dargestellt. Damit wird angezeigt, dass die UIDs als Attribute in der Intersection Entity übernommen werden.

45. Übungsbeispiel

46. CRUD Analyse Create, Retrieve, Update, Delete 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.

47. Composite UID zusammengesetzter Schlüssel dann notwendig, wenn ein Attribut nicht reicht

48. Composite UID & Barred Rel. Oft wird aus der übergeordneten Entity der Primary UID als Teil des Schlüssels übernommen UID Account: #BankNumber + #AccountNumber

49. Artificial UID Oft existiert kein passendes Attribut für einen UID. In diesem Fall muss ein „künstlicher“ Schlüssel modelliert werden.

50. Candidate UID Manchmal existieren mehrere Attribute, welche sich für einen UID eigenen. In diesem Fall soll der „beste“ UID ausgewählt werden.

51. Erste Normalform „Es gibt keine Attribute mit wiederholten Werten.“ -

52. Übungen Wo ist die erst NF nicht erfüllt?

53. Übungen Wo ist die erst NF nicht erfüllt?

54. Zweite Normalform Was ist bei diesem Beispiel mit einem Composite UID problematisch? Was passiert wenn ein Lieferant 100 Produkte anbietet und sein Name geändert werden muss?

55. Zweite Normalform „Alle Attribute müssen vom gesamten Schlüssel logisch abhängig sein.“ Bank location ist nicht von AccountNumber und BankNumber sondern nur von der BankNumber abhängig und muss in der Entity Bank gespeichert werden.

56. Übung

57. Übung

58. Dritte Normalform Was ist bei diesem Beispiel problematisch? Sollen die Informationen über Name und Anschrift des Geschäfts wirklich in der Entity CD gespeichert werden?

59. Dritte Normalform „Kein Attribut darf von einem anderen Attribut (das nicht zum Schlüssel gehört) funktional abhängig sein.“

60. Übungen

61. Constraints Alle Regeln, Bedingungen und Einschränkungen werden „Constraints“ genannt. Diese können sich auf Attribute, Entitäten und Beziehungen beziehen. zB.: Eine Bestellung muss von einem Mitarbeiter gemacht werden – keine Selbstbedienung (Constraint bei Beziehung)

62. Arcs Mit Arcs können „ODER“ Beziehungen dargestellt werden. zB eine Instanz von Billboard kann entweder eine Beziehung zu Movie, ProductAdvertisement oder Public Announcement haben. Arcs und Subtypes können oft alternativ verwendet werden. Kreise kennzeichnen die betroffenen Beziehungen!

63. Übung 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. Draw the entities and represent the exclusive relationship.

64. Hierarchische Beziehungen Für Organisationsdiagramme, Gebäudestrukturen, Stammbäume etc.

65. Rekursive Beziehungen Entities können auch Beziehungen zu sich selbst haben. zB.: Mitarbeiter, die auch gleichzeitig Vorgesetzte sein können.

66. Vergleich Manchmal können sowohl rekursive als auch hierarchische Beziehungen verwendet werden. Versuche die Vor- und Nachteile beider Lösungen herauszuarbeiten!

67. Übung Develop two ER diagrams to represent the following situation. Develop one using a hierarchical structure and one using a recursive structure. “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. 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. 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 Oracle Academy 1 Database Design Copyright © 2008, Oracle. All rights reserved. Oracle Academy 2 Database Design Copyright © 2008, Oracle. All rights reserved. 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.”

68. Historische Daten Wenn sich Daten im Lauf der Zeit ändern (zB Gehalt, Preis etc.) ist es oft sinnvoll die Historie zu speichern.

69. Übung “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.” Ändere das Modell rechts sodass die oben dargestellten Anforderungen erfüllt sind.!

70. Veränderungen : Zeit Beispiel: Ein Bierlieferant möchte bei jedem Verkauf auch die Tagestemperatur erfassen: Die 3. NF ist verletzt! Daher muss anders modelliert werden.

71. Veränderungen: Zeit Beispiel: Für eine Ausstellung sollen Freiwillige in Schichten an einem Stand stehen.

72. Übung 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? Wie kannst du die Problemstellung lösen?

73. Veränderungen: Preis Häufig (eigentlich fast immer) sind auch Preise veränderbar. Und sehr oft muss man wissen, wie viel ein Produkt an einem bestimmten Tag gekostet hat.

74. Übung “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. “ Zeichne ein ER-Modell (2 oder 3 Entities) für diese Problemstellung.

75. Das Relationenmodell

78. Constraints

79. Vom ERD zum Relationenmodell Bsp.: Wichtig: Es müssen diverse Regeln beachtet werden! Bitte diese in Section 11 genau durcharbeiten! „Relationship Mapping“

80. Einführung in SQL SQL = Structured Query Language Datenbanksprache für „alle“ Aufgaben zB.: Tabellen anlegen, Daten hinzufügen und löschen, Tabellen auswerten.

81. Einige Befehle DESCRIBE demo; SELECT * FROM demo; INSERT INTO demotable VALUES (10,‘A‘,20); ALTER TABLE demo ADD (plz CHAR(6)); ALTER TABLE demo DROP COLUMN plz; DELETE FROM TABLE demo WHERE id=5; … und viele viele weitere mehr….

82. Kategorien von SQL DML (Data manipulationlanguage)zB.: INSERT, UPDATE, DELETE DDL (Data definitionlanguage)zB.: CREATE, ALTER, DROP TCL (Transaction controllanguage)zB.: COMMIT, ROLLBACK DCL (Data controllanguage)zB.: GRANT, REVOKE

83. Übung Und nun selbständig: 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. 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. Übung: „BASIC SQL COMMANDS“

84. Aufbau Klausel (clause) Schlüsselwort (keyword) Anweisung (statement) Ende der der Anweisung mittels ;

85. Select Anweisung Bsp.: SELECT nn, vn FROM kunden WHERE id=3;

86. Select Anweisung

87. Join

88. Spalten auswählen SELECT id, title, duration, artist, type_code FROM d_songs; oder Alle Spalten SELECT * FROM d_songs; SELECT id, title, FROM d_songs; Bestimmte Spalten

89. Berechnungen +, -, * / Klammern können verwendet werden SELECT last_name, salary, salary + 300 FROM employees; Rangfolge der Operatoren („Precedence“) beachten: MyDearAuntSally

90. NULL-Werte NULL = „NIX“ NULL * irgendwas = „NIX“ NULL + irgendwas = „NIX“ usw. Achtung: 3/NULL „NIX“ 3/0  Fehler!!!

91. ALIAS Ausgabefelder können anders benannt werden: SELECT id AS id_nummer FROM demo; SELECT id AS “ID Nummer“ FROM demo; Oder: Bei Leerzeichen, Sonderzeichen und Groß-/Kleinschreibung

92. Übung: „Zum Aufwärmen“

93. „Concatenation“ Mit || können Ausdrücke verknüpft werden: zB.: SELECT last_name || ‘ ‘ || first_name AS full_name FROM employees;

94. DISTINCT Mit DISTINCT können Duplikate aus der Ergebnismenge entfernt werden. zB.: SELECT DISTINCT department_id FROM employees;

95. Übung: „Einfache SELECT Anweisungen“

96. WHERE… Mit einer „WHERE“ Klausel kann die Ergebnissmenge eingeschränkt werden. zB.: SELECT * FROM employees WHERE id=3;SELECT * FROM employeesWHERE first_name = ‘Huber‘; Logische Operatoren: = > >= < <= <> bzw. != oder ^=

97. WHERE… Weitere Möglichkeiten: … WHERE jahrBETWEEN 2000 AND 2010 … WHERE plzIN (4560, 4030, 4600) … WHERE jahr > 2000 ANDjahr < 2010 … WHERE plz=4560 ORplz=4030 Natürlich gibt es auch ein NOT Bei allen logischen Operatoren ist die Reihenfolge der Berechnung zu berücksichtigen!

98. WHERE „Unscharfe Suche“ mit Platzhaltern … WHERE last_nameLIKE ‘Ma_r%‘ _ genau ein beliebiges Zeichen %  mehrere beliebige Zeichen „Escapesequence“: zB ‘‘

99. WHERE … Nach Nullwerten suchen… … WHERE last_nameIS NULL Achtung: last_name = NULL ist nicht möglich!

100. Sortieren … ORDER BY last_name; … ORDER BY first_name DESC; … ORDER BY last_name, first_name DESC;

101. Multiple RowFunctions AVG COUNT MAX MIN SUM Achtung: Das Ergebnis ist dann eine Zeile! Im Gegensatz dazu dienen Single RowFunctions zur Manipulation von Werten (zBSIN etc.)