PMG2022/DB Beleg/Carl
Aus ProgrammingWiki
Wiki-Quelltext dieser Seite.
<language>SQL</language>
Sammelkarten Datenbank mit verschiedenen Karten, Kunden und Interresenten
==Ziel der Datenbank==
[[Bild:Carl_Pokémon-TCG-First-Edition-Base-Set-PSA10-Charizard.png| right| thumb| Diese Karte wurde für 220000$ verkauft]]
Mit meiner Datenbank möchte ich eine Handelsplatform zwischen Sammelkarten Käufern und Verkäufern schaffen.
Ich habe dieses Thema gewählt, da ich in meiner Kindheit selbst Sammelkarten gesammelt habe, heute sammel ich zwar keine Karten mehr, aber mich fasziniert mitlerweile die Preisentwicklung verschiedener Karten und auch die unterschiedlichen Gründe für den Preisverlauf dieser. Zum einen gibt es einen reinen Sammlerwert der Karten (wie wertvolle Kunstwerke o.ä.) und zum anderen haben viele Karten auch einen spielerischen Wert, da bei so gut wie allen Karten ein Spielprinzip dahinter ist und dieses Spiel auch meist professionell gespielt wird und manche Karten durch ihre guten Fähigkeiten allein schon einen hohen Wert haben.
==ERM Model==
[[Bild:Carl_Image.png]]
'''Erklärung:'''
Die Unterteilung der physischen und virtuellen Karte ist notwendig, da es sehr viele physische Ableger einer virtuellen Karte gibt und die physischen Karten gleiche Attribute(z.B. Name) haben aber auch unterschiedliche (z.B. Wert).Das Dreieck zwischen Kunde, phy.- und virtuller Karte ist nötig, da
* -ohne Beziehung zwischen Kunde und phy. Karte nicht klar ist wer diese verkauft
* -ohne Beziehung zwischen Kunde und vir. Karte nicht klar ist, ob der Kunde Interesse an der Karte hat
* -ohne Beziehung zwischen phy.- und vir. Karte nicht klar ist, welche vir. Karte die phy. Karte ist
Beziehungen:
* -Eine phy. Karte gehört zu einer vir. Karte, eine vir. Karte hat mehrere phy. Ableger (1:n)
* -Eine phy. Karte kann von einen Kunden verkauft werden, ein Kunde kann mehrere Karten verkaufen (1:n)
* -Ein Kunde kann an einer vir. Karte Interesse haben, eine vir. Karte kann von vielen Kunden gewünscht werden (m:n)
* -Eine vir. Karte gehört zu einer Marke, eine Marke hat mehrere vir. Karten (1:n)
* -Eine Marke wird von einem Herausgeber vertrieben, ein Herausgeber kann mehrere Marken vertreiben(1:n)
==Relationenmodel==
[[Bild:Carl_Unbenannt.png]]
'''Erklärung:'''
Die erste Normalform wurde schon im ERM Modell erfüllt (Es sind Attribute, wie der volle Name, schon getrennt).
Die Zweite Normalform wurde auch schon teilweise im ERM Modell erfüllt und die m:n Beziehung wurde mit einer Dritten Tabelle zu zwei 1:n Beziehungen
Die Dritte Normalform ist auch schon erfüllt, man kann zwar anbringen, dass man den Ort und das Land in eine extra Tabelle macht, da sie sich bedingen, jedoch ist es in der praxis nicht unbeding besser, da viele kleine Orte nur einzelne Kunden haben, und diese dann mit einer extra Tabelle mehr Speicherplatz wegnehmen würden, als wenn die beiden Punkte nicht getrennt würden. Außerdem kann ein Ortsname in verschiedenen Ländern auftauchen.
Ansonsten wurden alle 1:n Beziehungen mit einem Fremdschlüssel auf der n Entität übertragen, und 1:1 gab es nicht.
==Datenbank==
<code id="62344745ed69f">
DROP TABLE IF EXISTS phy_Karte;
CREATE TABLE phy_Karte (
ID varchar(6),
KartenID varchar(9),
KundenID varchar(8),
Zustand varchar(10),
Wert decimal(10)
);
Insert into phy_Karte Values ("000000", "000000", "00000", "gut",0.27) ;
Insert into phy_Karte Values ("000001", "000001", "00000", "schlecht",1) ;
Insert into phy_Karte Values ("000002", "000003", "00001", "mittel",6) ;
Insert into phy_Karte Values ("000005", "000003", "00002", "schlecht",2) ;
Insert into phy_Karte Values ("000006", "000003", "00002", "gut",6) ;
Insert into phy_Karte Values ("000007", "000003", "00003", "sehr gut",15) ;
Insert into phy_Karte Values ("000008", "000003", "00002", "gut",6) ;
Insert into phy_Karte Values ("000009", "000003", "00000", "gut",7) ;
Insert into phy_Karte Values ("0000010", "000003", "00000", "super",19.99) ;
Insert into phy_Karte Values ("000003", "000002", "00001", "mittel",4.15) ;
Insert into phy_Karte Values ("000004", "000004", "00001", "super",220000) ;
DROP TABLE IF EXISTS Kunde;
CREATE TABLE Kunde(
ID varchar(8),
Name varchar(20),
Vorname varchar(20),
Wohnort varchar(40),
Strasse varchar(40),
Land varchar(20),
Hausnummer varchar(3)
);
Insert into Kunde Values ("00000", "Mueller", "Heinz","Dresden","Lindenstrasse", "Germany", "5");
Insert into Kunde Values ("00001", "Smith", "Will","London","Downing_street", "UK", "5");
Insert into Kunde Values ("00002", "Lillard", "Samuel","Housten","Houstenroad", "USA", "5");
Insert into Kunde Values ("00003", "Rotriges", "Fernando","Madrid","Gran_Via", "Spain", "5");
DROP TABLE IF EXISTS vir_Karte;
CREATE TABLE vir_Karte (
ID varchar(9),
MarkenID varchar(5),
Name varchar(25),
Erscheinungsjahr varchar(4)
);
Insert into vir_Karte Values ("000000", "00001", "Gilde Lotus", "2018");
Insert into vir_Karte Values ("000001", "00002", "General Grievous", "2010");
Insert into vir_Karte Values ("000002", "00002", "Obi-Wan-Kenobi", "2010");
Insert into vir_Karte Values ("000003", "00000", "Charizard", "2022");
Insert into vir_Karte Values ("000004", "00000", "Charizard", "1996");
DROP TABLE IF EXISTS Interesse;
CREATE TABLE Interesse (
ID varchar(9),
ExemplarID varchar(9),
KundenID varchar(9)
);
Insert into Interesse Values ("000000", "000004", "00001");
Insert into Interesse Values ("000001", "000003", "00000");
Insert into Interesse Values ("000002", "000001", "00003");
DROP TABLE IF EXISTS Marke;
CREATE TABLE Marke(
ID varchar(5),
HerausgeberID varchar(9),
Name varchar(15),
Erscheinungsjahr varchar(4)
);
Insert into Marke Values ("00000", "00000", "Pokemon","1996") ;
Insert into Marke Values ("00001", "00000", "Magic:The_Gathering","1993") ;
Insert into Marke Values ("00002", "00001", "Star_Wars","2010") ;
DROP TABLE IF EXISTS Herausgeber;
CREATE TABLE Herausgeber(
ID varchar(5),
Firmensitz varchar(15),
Name varchar(20),
Gruendungsjahr varchar(4)
);
Insert into Herausgeber Values ("00000", "Renton", "Wizards_of_the_Coast","1990") ;
Insert into Herausgeber Values ("00001", "New_York_City", "Topps","1938") ;
</code>
In der Datenbank wurden einige Namen abgekürzt bzw. verändert.
*physische Karte --> phy_Karte
*virtuelle Karte --> vir_Karte
*virtuelleKundenID --> KundenID und ExemplarID
==Abfragen==
Einfache Abfrage: Es sollen alle Kartenmarken der Spielefirma "Wizards of the Coast" gesucht werden
<run id="623448a2f3540">
Select m.Name,m.Erscheinungsjahr from Herausgeber as h, Marke as m where h.Name = "Wizards_of_the_Coast" and m.HerausgeberID = h.ID;
</run>
Mittelschwere Abfrage: Es sollen alle möglichen Physischen Karten angezeigt werden, bei welchen der Nutzer mit der ID "00000" Interesse hat
<run id="623dd209a4276">Select vk.Name, pk.Zustand, pk.Wert as "Wert in $", k2.Name as "Verkäufername", k2.Vorname as "Verkäufervorname", k2.Wohnort as "Ort", k2.Land
from Kunde as k, phy_Karte as pk, Interesse as i, Kunde as k2, vir_Karte as vk where
i.KundenID = k.ID and i.ExemplarID = pk.KartenID and k.ID = "00000" and k2.ID = pk.KundenID and vk.ID = pk.KartenID;</run>
Schwerere Abfrage: Es soll nach der billigsten physischen Karte gesucht werden, welche ein "Charizard" ist, mindestens einen Zustand von Gut hat und wo der Verkäufer aus Deutschland kommt
<run id="623dd2ec45884">Select vk.Name, pk.Zustand, (Min(pk.Wert)) as "Wert in $", k.Name,k.Vorname, k.Wohnort, k.Land from phy_Karte as pk, Kunde as k, vir_Karte as vk where
vk.Name = "Charizard" and vk.ID = pk.KartenID and pk.KundenID = k.ID and k.Land = "Germany" and (pk.Zustand = "gut" or pk.Zustand = "sehr gut" or pk.Zustand = "super" )</run>
== kritsche Reflexion ==
'''Unnötige Entität:'''
Die Idee hinter dieser Datenbank ist es eine Platform für Sammelkarten Käufer und Verkäufer zu schaffen. Dabei kann der Markenname sehr bei der Navigation durch die Datenbank helfen. Die Entität "Herausgeber" hätte man jedoch wahrscheinlich auch weg lassen können, da sie in der Praxis wohl nicht so häufig gebraucht wird.
'''ID kann zu groß werden:'''[[Bild:Carl_Unbenandnt.png | right]]
Die ID der physischen Karte ist bei jeder Einzelnen Karte untershiedlich, dass ist bei kleinen Datenmengen kein Problem, jedoch bei größeren Datenmengen könnte dies zu einem Problem werde, so wurde allein letztes Jahr 3,7 Milliarden Pokémon Karten verkauft.[https://www.ntower.de/news/73901-beliebt-wie-eh-und-je-the-pok%C3%A9mon-company-verkaufte-3-7-milliarden-pok%C3%A9mon-karte/] Man könnte es so machen, dass die ID der physischen Karte nur spezifisch für die virtuelle Karte ist, damit ist die ID der physischen Karte zwar nicht mehr Einzigartig, jedoch die Kombination von der phyischen Karten ID und der virtuellen Karten ID. Siehe Beispiel
'''ID Längen sind unzureichent:'''
Die Ids habe Momentan eine Größe von 10^6 bzw 10^5, das ist bei viellen Daten zu wenig und müsste erhöht werden.
'''Fehlende Attribute:''' Die wichtigsten Attribute sind schon gegeben, jedoch für einige Werte muss es noch mehr geben(z.B. PLZ bei Kunde oder Rarität bie virtueller Karte)
'''Variablentypen:''' Ich habe, bis auf eine Ausnahme, immer den Variablentypen varchar benutzt, dieser verbraucht jedoch vergleichsweise viel Speicher, deshalb wäre eine Spezifizierung in andere Typen wie text oder char() manchmal die bessere Wahl gewesen.
== Quellen und Tools ==
'''Quellen:'''
* [https://www.cardmarket.com/de Infos über Karten + Inspiration der Datenbank]
* [https://www.collect-it.de Infos über Star Wars Karten ]
* [https://www.ntower.de/news/73901-beliebt-wie-eh-und-je-the-pok%C3%A9mon-company-verkaufte-3-7-milliarden-pok%C3%A9mon-karte/ Info von Kartenmenge]
* [https://wikis.gm.fh-koeln.de/Datenbanken/SQL-Datentyp Variablentyp Decimal]
'''Tools:'''
* [https://erdplus.com/ ERDplus]
* [https://www.microsoft.com/de-de Microsoft Paint]
* [https://www.google.at/drive/about.html Google Drive (Docs)]