Das Dokument bietet eine Übersicht über Datenbank-Design im Rahmen eines Kurses der Oracle Academy. Es behandelt die Strukturierung von Daten in Datenbanken, den Entwicklungsprozess von ER-Modellen sowie dessen Umsetzung in physische Modelle, und erläutert dabei wichtige Konzepte wie Entitäten, Attribute, Beziehungen und Constraints. Zudem werden verschiedene Übungen und SQL-Befehle zur Datenmanipulation vorgestellt, um das Verständnis für Datenbankdesign und -anwendung zu fördern.

1. ÜbersichtFolien 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 InformationenDatenInformationen„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 EntwicklungsprozessInformationsbedarf definierenEntwurf eines DB-Konzepts(ER-Modell)Datenbankdesign(Relationales Modell entwerfen)Datenbank erstellen bzw. programmieren(SQL)

5. Konzept versus phys. ModellKonzeptPhysisches ModellAnalyse und Planung der DBRein an den Bedürfnissen des Unternehmens orientiertKümmert sich nicht um die Implementierung (= wie und womit „programmiert“) ER-ModellKonkrete Umsetzung des KonzeptsOrientiert sich am technisch machbaren und der zugrundeliegenden Software

6. Entity und InstanceInstanceEntityEine Name für ähnliche Dingemeist ein HauptwortEin konkretes „Ding“Unterscheidung:tangible

7. non tangible

8. EventsAttribut… beschreibt eine Entity genauer(Qualität, Quantität etc.)Wichtig!Konkrete „Werte“ nur bei Instanzen.

9. Immer nur ein „Wert“.

10. Manche Attribute müssen eine Wert haben, andere wieder nicht.Unterscheidung: volatile

11. non volatileIdentifier (UID) Jede Instanz wird durch ein Attribut eindeutig gekennzeichnet (UID – unique identifier) kann auch eine Kombination mehrerer Attribute sein.Beispiele…

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-ModellsAlle 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 DiagrammkonventionenKUNDE# Kunden_id* Vorname* Nachnameo Emailadresse…MAHNUNG# Mahnung_id* Datumo Anmerkung….bekommtbezieht sich aufKardinalitä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. ÜbungsbeispieleZeichne ein ER-Diagramm zu folgendem Fall und schreibe die Beziehung in „ERDish“ an.

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

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

26. MatrixdiagrammeBeinhaltet NICHT Optionalität

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

28. ÜbungsbeispielErstelle zu folgendem ER Diagramm ein Matrixdiagramm

29. Supertypes & SubtypesEine Enity kann in „Subtypen“ strukturiert werden.Der Subtyp erbt alle Attribute des Supertyps

30. alle Beziehung des SupertypsDer Subtyp hat natürlich eigene Attribute

31. und kann eigene Beziehungen habenSupertypes & SubtypesBeispiel einer Enity mit Subtypen sowie Beziehungen zum Supertypen als auch untergeordneten Subtypen

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

33. Übung

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

35. Business RolesProceduralRoles(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 TransferabilityOptionality: 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 TransferabilityNicht transferierbare Beziehungen werden mit einer Raute („Diamond“) gekennzeichnetBeispiele: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. Beziehungstypen1:N Beziehung

40. BeziehungstypenM:N BeziehungenMeistens 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. Beziehungstypen1:1 BeziehungenKönnte man dieses Beispiel auch anders modellieren?

42. Redundante BeziehungenZwischen 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ösenM:N Beziehungen können in zwei1:N Beziehungen aufgelöst werden.Die neu entstandene Entity wird Intersection Entity genannt.Dies ist aber im Design nur für die bessereVerständlichkeit notwendig.Bei der physischen Umsetzung in ein Daten-Modell muss meist zwingendend eine Auflösung erfolgen.

44. Barred RelationshipsWird 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 AnalyseCreate, Retrieve, Update, DeleteDie 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 UIDzusammengesetzter Schlüsseldann notwendig,wenn ein Attributnicht reicht

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

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

50. Candidate UIDManchmal 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. ÜbungenWo ist die erst NF nicht erfüllt?

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

54. Zweite NormalformWas 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 NormalformWas 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. ConstraintsAlle 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. ArcsMit 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. ÜbungA 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 BeziehungenFür Organisationsdiagramme,Gebäudestrukturen, Stammbäume etc.

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

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

67. ÜbungDevelop 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 DatenWenn 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 : ZeitBeispiel: Ein Bierlieferant möchte bei jedem Verkauf auch die Tagestemperatur erfassen:Die 3. NF ist verletzt!Daher muss anders modelliert werden.

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

72. ÜbungEach 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: PreisHä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

76. Primärschlüssel Kann zusammengesetzt sein

77. Darf nicht „NULL“ seinFremdschlüsselWenn der Fremdschlüssel selbst Teil des Primärschlüssels ist, dann darf dieser nicht NULL sein!

78. Constraints

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

80. Einführung in SQLSQL = Structured Query LanguageDatenbanksprache für „alle“ AufgabenzB.: Tabellen anlegen, Daten hinzufügen und löschen, Tabellen auswerten.

81. Einige BefehleDESCRIBE 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 SQLDML (Data manipulationlanguage)zB.: INSERT, UPDATE, DELETEDDL (Data definitionlanguage)zB.: CREATE, ALTER, DROPTCL (Transaction controllanguage)zB.: COMMIT, ROLLBACKDCL (Data controllanguage)zB.: GRANT, REVOKE

83. ÜbungUnd 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. AufbauKlausel (clause)Schlüsselwort (keyword)Anweisung (statement)Ende der der Anweisungmittels ;

85. Select AnweisungBsp.:SELECT nn, vnFROM kundenWHERE id=3;

86. Select Anweisung

87. Join

88. Spalten auswählenSELECT id, title, duration, artist, type_codeFROM d_songs;oderAlle SpaltenSELECT * FROM d_songs;SELECT id, title, FROM d_songs;Bestimmte Spalten

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

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

91. ALIASAusgabefelder können anders benannt werden:SELECT id AS id_nummer FROM demo;SELECT id AS “ID Nummer“ FROM demo;Oder: Bei Leerzeichen, Sonderzeichenund 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. DISTINCTMit 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 employeesWHERE id=3;SELECT * FROM employeesWHERE first_name = ‘Huber‘;Logische Operatoren:=>>=<<=<> bzw. != oder ^=