Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Datenbankschema - Tabellenverknüpfung (https://www.delphipraxis.net/207361-datenbankschema-tabellenverknuepfung.html)

NoGAD 17. Mär 2021 11:24

Datenbank: ABS_Database • Version: 7.92 • Zugriff über: ABSTable/ABSQuery

Datenbankschema - Tabellenverknüpfung
 
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,

im Anhang habe ich ein Schema (in Libreoffice erstellt) angehängt, wie ich mir die Relation meiner Datenbank vorstelle. Die Feldlänge, gerade bei den Verweisen auf andere Tabellen (id) habe ich meist mit 25 wohl zu hoch angesetzt, was wäre hier für ein gängiger Wert?

Ist das vom logischen Aufbau so in Ordnung?

LG Mathias

haentschman 17. Mär 2021 11:32

AW: Datenbankschema - Tabellenverknüpfung
 
Zitat:

Ist das vom logischen Aufbau so in Ordnung?
...mir ist nur der Umlaut "Ü" aufgefallen. Manche DBMS könnten allergisch reagieren...Wenn man alles in englisch macht, hat man solche Probleme nicht. :zwinker:

Delphi.Narium 17. Mär 2021 12:03

AW: Datenbankschema - Tabellenverknüpfung
 
Integer umfasst (für gewöhnlich) den Wertebereich von −2.147.483.648 bis 2.147.483.647, das sind 10 Stellen. Ob Du wohl jemals so viele Bücher verwalten wirst?

Im Beispiel für ein Create Table (https://www.componentace.com/sql/create-drop-table.htm) ist bei Integer kein Wert für die Größenangabe vorgesehen, was durchaus üblich ist. Es kann also gut sein, dass Du hier nichts angeben musst, analog zu z. B. Boolean, Date ...

Für den Preis würd' ich jetzt nicht unbedingt einen String wählen. Zulässige Datentypen sind hier https://www.componentace.com/help/ab...ddatatypes.htm zu finden. Bei Preisen handelt es sich um Währungsangaben, da wäre dann wohl der Datentyp Currency angebracht.

Wenn der Preis als Currency angegeben wird, kann man dann eventuell später auch mal die Summe aller Bücherpreise berechnen oder den Durchschnittspreis aller Bücher oder die Summe der Buchpreise zu Autor X oder Verlag Y, ... Bei 'nem String für die Preisangabe wird das eher sportlich und fehleranfällig.

NoGAD 17. Mär 2021 13:12

AW: Datenbankschema - Tabellenverknüpfung
 
Vielen Dank!

Das ist wirklich sehr schöne konstruktive Hilfe.

Umlaute fliegen raus :-)

Die Feldgröße für Integerwerte hatte ich tatsächlich übersehen.

Auch das mit dem Preis ist tatsächlich besser.

LG Mathias.

NoGAD 17. Mär 2021 14:35

AW: Datenbankschema - Tabellenverknüpfung
 
Liste der Anhänge anzeigen (Anzahl: 1)
Ich habe eine Nachfrage.


Ist die Tabelle table_bibo2 überhaupt nötig bzw. sinnvoll? Eigentlich könnte ich diese doch weglassen, ist mir eben aufgefallen.

Die Haupttabelle wäre dann table_book.

Im Anhang eine neue Aufstellung der Tabellen, in englisch.

LG Mathias

mikhal 17. Mär 2021 14:53

AW: Datenbankschema - Tabellenverknüpfung
 
Die Tabelle macht so wirklich keinen Sinn. Wenn du mehrere Bibliotheken verwalten willst, ist der Ansatz sowieso falsch. Dann müsstest du in der Table_book einen Verweis auf die Bibliothek haben - nicht umgekehrt.

Grüße
Mikhal

Jumpy 17. Mär 2021 15:13

AW: Datenbankschema - Tabellenverknüpfung
 
Warum lagerst du die Description aus? Thumbnail kann ich ja ggf. noch verstehen.

borowto und borowdate?
Für die Verwaltung der Ausleihen würde ich eigene Tabellen verwenden.

Die bibo Tabelle könnte schon Sinn machen, wenn es ein Buch mehrfach gibt. Dann ist in bibo die Buchinstanz und es wird dann auch eine konkrete Buchinstanz verliehen.

Delphi.Narium 17. Mär 2021 15:18

AW: Datenbankschema - Tabellenverknüpfung
 
Könnte man weglassen.

Wenn man das Programm aber mal ausbauen will, um damit auch CDs, DVDs, VHS-Vidokassetten (wir sind ja schon was älter), Musiknoten und was sonst noch ... verwalten will, dann könnte man diese Tabelle erweiteren und anhand der Auswahl dort auf unterschiedliche Programmteile verzweigen, könnte aber ggfls. auch Verknüpfungen unter den Tabellen zu den verschiedenen Themenbereichen erstellen. Z. B.: Haben wir zu dem Titel xy auch die passenden Noten und auf welchen CDs ... ist er ebenfalls zu finden, jedenfalls ist er in dem Liederbuch im Regal a, Fach b, sowie als MusicXML ... vorhanden.

Ok: Wäre dann erstmal nur Spielerei, aber wer weiß, was noch daraus wird.

Ließe sich ggfls. dann später "nachmodelieren". Momentan jedenfalls absolut entbehrlich.

Die ISBN ist eine Nummer und kein String (fällt mir gerade noch so ein). Es gibt sie in zwei Varianten, als 10-stellige Zahl oder als 13-stellige Zahl. String 42 ist da irgendwie seltsam.

https://de.wikipedia.org/wiki/Intern...dardbuchnummer

Die ISBN 10 ist die ISBN 13 abzüglich der ersten drei Ziffern zuzüglich der Neuberechnung der Prüfziffer an der letzten Stelle. Genaugenommen handelt es sich hier um eine Redundanz. Aus ISBN 13 bekommt man über definierte Regeln immer ISBN 10. Persönlich würd' ich nur die ISBN 13 speichern. Aus ISBN 13 bekommt man im Bedarfsfall immer ISBN 10. Ob man aus ISBN 10 immer auf die führende 978 bzw. 979 der ISBN 13 zurückschließen kann, weiß ich nicht.

Delphi-Quellcode:
{als reine Ziffernfolge} Copy(ISBN13,4,9) = Copy(ISBN10,1,9)
{nach ISO formatiert} Copy(ISBN13,4,14) = Copy(ISBN10,1,12)
Die Bindestriche, Leerzeichen, ... in den Nummern sind was für die Menschen, die das dann ggfls. besser lesen können, aber eigentlich nicht für die Abspeicherung erforderlich.
Zumal: Wenn man die Bindestriche korrekt setzen will, so sind sie abhängig davon zu setzen, zu welchem Land, zu welcher Gruppennummer, zu welchem Verlag sie gehört. Der Rest ist dann die Nummer des Titels, gefolgt von der einstelligen Prüfziffer. Bei der Beachtung der Formatierregeln für die Anzeige, wird eine ISBN 13 17 Zeichen lang. Wenn man dann noch das ISBN mit speichert, kommt man auf 22 Zeichen. Beim Speichern der Bindestriche muss man natürlich String als Datentyp wählen.

borstenei 17. Mär 2021 15:55

AW: Datenbankschema - Tabellenverknüpfung
 
Ein Autor kann doch aber mehr als ein Buch schreiben, wenn jetzt bei diesem Tabellenaufbau 5 Bücher von Grisham eingegeben werden erscheint doch auch in der Tabelle Autor 5 x der Name John Grisham :roll:
und das sollte doch vermieden werden.

Jumpy 17. Mär 2021 16:02

AW: Datenbankschema - Tabellenverknüpfung
 
Zitat:

Zitat von borstenei (Beitrag 1485370)
Ein Autor kann doch aber mehr als ein Buch schreiben, wenn jetzt bei diesem Tabellenaufbau 5 Bücher von Grisham eingegeben werden erscheint doch auch in der Tabelle Autor 5 x der Name John Grisham :roll:
und das sollte doch vermieden werden.

Nee das ist schon OK so. In Autor ist ja der Fremdschlüssel auf die Autor-Tabelle gespeichert.

Aber: Ein Buch kann auch mehrere Autoren haben, deswegen ist das zwichen Buch und Autor eigentlich eine n:m Beziehung die über eine Zwischentabelle abzubilden ist.

Delphi.Narium 17. Mär 2021 16:11

AW: Datenbankschema - Tabellenverknüpfung
 
Was ich gerade noch gefunden habe: Die ISBN 10 gibt es nur zu den Büchern, deren ISBN 13 mit 978 beginnt. Zu den Büchern mit 'ner mit 979 beginnenden ISBN 13, gibt es keine ISBN 10. Von daher sollte man wohl eher auf die ISBN 10 verzichten.

NoGAD 17. Mär 2021 18:35

AW: Datenbankschema - Tabellenverknüpfung
 
Hallo und danke für die vielen Antworten.

Ganz zu Beginn erst einmal eine Klarstellung: Das Programm ist keines, welches ich für eine Bibliothek erstellen möchte. Es ist ein kleines Lernprojekt für mich und weiterhin eine Anwendung für meinen Vati. Er hat gerne Ordnung.


Die ISBN10 benötige ich, weil viele Bücher im Bestand meines Vatis noch aus DDR-Zeiten sind. Damals gab es keine ISBN13.
Außerdem habe ich die 42 als Größe gewählt, weil das doch die Antwort auf ALLES ist.. :lol:
Spaß beiseite, ich war mir tatsächlich nicht sicher, wie die ISBN von jemandem eingegeben wird und habe daher das Feld entsprechend ausgedehnt.

Zitat:

Zitat von Jumpy (Beitrag 1485371)
Ein Buch kann auch mehrere Autoren haben

Dafür habe ich eigentlich keine extra Abbildung vorgesehen. In so einem Fall wäre dann z.B. ein Autorenduo auch als solches im Feld einzutragen. (Douglas Preston & Liconln Child aká Preston & Child fallen mir hier als Beispiel ein, die schreiben auch als Einzelautoren ihre Bücher)

Zitat:

Zitat von Delphi.Narium (Beitrag 1485368)
Wenn man das Programm aber mal ausbauen will, um damit auch CDs, DVDs, VHS-Vidokassetten

Eine gute Idee, die verfolge ich dann später weiter :-)

Zitat:

Zitat von Jumpy (Beitrag 1485367)
Warum lagerst du die Description aus? Thumbnail kann ich ja ggf. noch verstehen.

borowto und borowdate?
Für die Verwaltung der Ausleihen würde ich eigene Tabellen verwenden.

Die Description ist ja ein Memo-Feld. Ich hoffte, dass mit der ABSDatabase somit eine Trennung und durch Komprimierung, ein Geschwindigkeitsvorteil erreicht werden kann.

Die Ausleihe ist pro Buch, daher sollte die doch auch dort zu finden sein. Eine extra Tabelle, dachte ich, macht hier wenig Sinn.


LG Mathias :-)

Delphi.Narium 18. Mär 2021 11:23

AW: Datenbankschema - Tabellenverknüpfung
 
Zitat:

Zitat von NoGAD (Beitrag 1485390)
Hallo und danke für die vielen Antworten.

Ganz zu Beginn erst einmal eine Klarstellung: Das Programm ist keines, welches ich für eine Bibliothek erstellen möchte. Es ist ein kleines Lernprojekt für mich und weiterhin eine Anwendung für meinen Vati. Er hat gerne Ordnung.


Die ISBN10 benötige ich, weil viele Bücher im Bestand meines Vatis noch aus DDR-Zeiten sind. Damals gab es keine ISBN13.

Bezüglich ISBN13, die kann man aus der ISBN10 berechnen.

ISBN13 ist gleich 978 plus die ersten 9 Ziffern der ISBN10 plus neuberechnete Prüfziffer. Das gilt auch für die ISBN10 aus Zeiten, zu denen es noch keine ISBN13 gab.

Bezüglich alter Buchbestand: Das ISBN13-Feld sollte not null sein, damit man keine Bücher ohne ISBN erfassen kann, derweil die sind im Buchbestand ja (vermutlich / eventuell) auch vorhanden ;-)

Da not null und keine ISBN natürlich nicht funktioniert, gibt es auch dafür einen Lösungsansatz: Im Nummernbereich der ISBN13 gibt es nichtvergebene Gruppennummern, z. B. 978650. Die könnte man dann gut für solche Bücher verwenden. Das erste derartige Buch bekommt dann die ISBN13 9786500000016, das zweite 9786500000023, ... Damit kann man dann ggfls. per SQL auch mal genau alle diese Bücher als Report ... ausgeben lassen, ebenso, wie man über die Gruppennummer alle Bücher aus bestimmten Ländern ausgeben lassen kann oder alle Bücher eines Verlages, ... Dazu werden dann die Informationen aus der "Verlagstabelle" nicht mal benötigt. Strenggenommen ist ein Fremdschlüssel auf den Verlag in der Tabelle der Buchtitel eine Redundanz (und damit bei einer vollständigen Normalisierung des Datenmodels nicht zulässig). Man könnte diesen Verweis auch über die ISBN13 herstellen (was allerding eher etwas überkompliziert wäre, da man dazu dann auch ein vollständiges Gruppennummern- bzw. ein vollständiges Verlagsverzeichnis benötigen würde).

Man könnte also bei der Eingabe der ISBN prüfen, ob diese 10-stellig ist und dann daraus sofort die ISBN13 berechnen. Da es ja ein Lernprojekt ist, halte ich diese Umsetzung für zwingend. Und das Argument: Ist mir zu schwer gilt nicht, derweil passende Lösungsansätze sind hier im Forum bereits zu finden ;-)
Zitat:

Das Programm ist keines, welches ich für eine Bibliothek erstellen möchte. Es ist ein kleines Lernprojekt für mich ...
Das war mir schon klar und genau deshalb bestehe ich auf einer möglichst perfekten Umsetzung, die erhöht halt den Lerneffekt und Zeitaufwand und "Kosten" sind dabei ja vernachlässigbar, weil keiner über "Kostenexplosion" oder "warum dauert das denn solange" ... schimpfen kann ;-)

Und nein: Das meine ich jetzt nicht wirklich so, aber eventuell hast Du ja Spass daran, das eine oder andere doch umzusetzen ;-)

Jumpy 18. Mär 2021 14:11

AW: Datenbankschema - Tabellenverknüpfung
 
Zitat:

Zitat von NoGAD (Beitrag 1485390)
Die Ausleihe ist pro Buch, daher sollte die doch auch dort zu finden sein. Eine extra Tabelle, dachte ich, macht hier wenig Sinn.

Für deinen Anwendungsfall hast du da sicher recht, ich dachte auch es ginge in Richtung Bibliotheksanwendung und da will man ja auch eine Historie haben, wer wann welches Buch geliehen hatte und wie lange.

NoGAD 19. Mär 2021 11:49

AW: Datenbankschema - Tabellenverknüpfung
 
Zitat:

Zitat von Delphi.Narium (Beitrag 1485429)
Das war mir schon klar und genau deshalb bestehe ich auf einer möglichst perfekten Umsetzung, die erhöht halt den Lerneffekt und Zeitaufwand und "Kosten" sind dabei ja vernachlässigbar, weil keiner über "Kostenexplosion" oder "warum dauert das denn solange" ... schimpfen kann ;-)

Und nein: Das meine ich jetzt nicht wirklich so, aber eventuell hast Du ja Spass daran, das eine oder andere doch umzusetzen ;-)

Ha. Da hast Du mich erwischt!

Ich werde daran denken :-)

Momentan bin ich erst einmal bei der Datenbankerstellung und der vernünftigen Implementierung. Wenn das klappt, kümmere ich mich um solche Dinge :-)

LG Mathias


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:02 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz