63
Eine Frage bezüglich Datenbank Normalisierung
Hallo an Alle.
Ich absolviere gerade eine Fortbildung zum geprüften Informatiker und habe da eine Frage bezüglich der Bewertung meiner Lösung, die ich nicht nachvollziehen kann.
Die Aufgabenstellung:
Die Tabelle:
Meine Lösung dazu:
Dafür hat er mir nur 22/30 Pkt. gegeben.
Nun meine eigentliche Frage dazu:
gehe ich richtig in der Annahme, dass seine Antwort in der Form nicht korrekt ist?
Aus meiner Sicht würde es dazu führen, dass man bei seiner Lösung Probleme hätte, bspw. die Telefonnummern, oder die E-Mail-Adressen abzufragen, da diese ja nicht eindeutig in der Datenbank zu ermitteln wären, wenn es mehrere davon für einen Kunden gibt.
Ein zusätzliches Attribut dafür (Privat/Geschäft) wäre ja auch nicht sinnvoll und die Begründung der "Lücken" ... naja das sind Null-Werte.
Außerdem dürfte es in der Praxis wohl kaum Kunden geben, bei denen mehr wie 3 Telefonnummern und 2 E-Mail-Adressen gespeichert werden.
Sehe ich das richtig, oder bin ich da völlig auf dem Holzweg?
Ich bin auf eure Antworten gespannt ...
LG
Ich absolviere gerade eine Fortbildung zum geprüften Informatiker und habe da eine Frage bezüglich der Bewertung meiner Lösung, die ich nicht nachvollziehen kann.
Die Aufgabenstellung:
Die Tabelle:
Meine Lösung dazu:
Dafür hat er mir nur 22/30 Pkt. gegeben.
Nun meine eigentliche Frage dazu:
gehe ich richtig in der Annahme, dass seine Antwort in der Form nicht korrekt ist?
Aus meiner Sicht würde es dazu führen, dass man bei seiner Lösung Probleme hätte, bspw. die Telefonnummern, oder die E-Mail-Adressen abzufragen, da diese ja nicht eindeutig in der Datenbank zu ermitteln wären, wenn es mehrere davon für einen Kunden gibt.
Ein zusätzliches Attribut dafür (Privat/Geschäft) wäre ja auch nicht sinnvoll und die Begründung der "Lücken" ... naja das sind Null-Werte.
Außerdem dürfte es in der Praxis wohl kaum Kunden geben, bei denen mehr wie 3 Telefonnummern und 2 E-Mail-Adressen gespeichert werden.
Sehe ich das richtig, oder bin ich da völlig auf dem Holzweg?
Ich bin auf eure Antworten gespannt ...
LG
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2195300632
Url: https://administrator.de/contentid/2195300632
Printed on: April 27, 2024 at 08:04 o'clock
63 Comments
Latest comment
gehe ich richtig in der Annahme, dass seine Antwort in der Form nicht korrekt ist?
Nein, da kommen jetzt 5 Mark ins Schweinchen.
Aus meiner Sicht würde es dazu führen, dass man bei seiner Lösung Probleme hätte, bspw. die Telefonnummern, oder die E-Mail-Adressen abzufragen, da diese ja nicht eindeutig in der Datenbank zu ermitteln wären, wenn es mehrere davon für einen Kunden gibt.
Wieso, du hast doch weiterhin die Kunden-ID?
Ich würde das genau so machen wie dein Dozent, beispielhaft an der Mailtabelle:
+---------------------------------------------------------+
| _ENr_ | KdNr | EMailAddr | AddrType |
+--------+--------+---------------------+-----------------+
| 1 | 1 | mm@meier.de | business |
|---------------------------------------------------------|
| 2 | 1 | max@meier.de | private |
|---------------------------------------------------------|
| 3 | 3 | schmitz@renate.de | private |
+---------------------------------------------------------+Über die KdNr hast du eine eindeutige Zuordnung wem eine E-Mail-Adresse gehört:
-- Query:
SELECT * FROM `EMail` WHERE `KdNr` = 1;
-- Result:
+---------------------------------------------------------+
| _ENr_ | KdNr | EMailAddr | AddrType |
+--------+--------+---------------------+-----------------+
| 1 | 1 | mm@meier.de | business |
|---------------------------------------------------------|
| 2 | 1 | max@meier.de | private |
+---------------------------------------------------------+Vorteil: Du kannst beliebig viele Adressen pro Kunde speichern und "mal eben" um weitere Typen erweitern.
Außerdem dürfte es in der Praxis wohl kaum Kunden geben, bei denen mehr wie 3 Telefonnummern und 2 E-Mail-Adressen gespeichert werden.
Meine Kunden haben den Chat betreten...
Wir speichern nämlich alle möglichen separaten Kontakte:
Administrativer Ansprechpartner, Technischer Ansprechpartner, Rechnungsempfänger, Empfänger für Mahnungen... Und all das mit teilweise mehreren Adressen pro Typ.
Lang ist's her @Tomtom33:
Deine Kunden Tabelle ist iO:
Jedem Kunde wurde eine Kundennummer zugeordnet, das ist der Primäre Schlüssel
Die Tabelle bleibt so
Deine 2. Tabellen Telefon/E-Mail hätte ich anderst integriert:
Definiere doch einfach mögliche Kommunikationstypen, hier lt Deinen Vorgaben auch hier als Primärschlüssel:
1- Privat
2- Mobil1
3- Mobil2
4- E-Mail Geschäftlich
5- E-Mail Privat
Jetzt füllst Du eine weitere, die 3. Tabelle wie folgt:
- Die Kombination von Kundennummer (Primärschlüsel) und Kommunikationstyp (Primärschlüssel) führt zu einem eindeutigem Datensatzinhalt bezüglich der Kommunikation (Beispiel für Kunde mit Nr1...usw):
- 1- 1 - 040/110112
- 1- 2 - 0170/12356789
- 1- 4 - mm@meier.de
- 1- 5 - max@meier.de
- 2 -1 - 030/1234987
- 3 -5 - Schmitz@renate.de
usw.....
Die Zuordnung der DS-Inhalte ist durch die Kombination der 2 Schlüssel eindeutig möglich.
Erweiterungen, mehr Tel-Nr/Mail-Adressen, kannst Du durch erweitern der Tabelle 2 einfach gestalten.
Die Antwort Deines Dozenten kann ich so erst mal nicht nachvollziehen ...
Und was meinst DU?
Ich schaue hier gerade auf eine meiner besseren Leistungen in Access ... die Beziehungen einer größeren Anwendung
und will Dir noch mal einen Gedankenhinweis/-anstoß geben:
In weiser Vorausicht hatte ich schon bei der Planung in einem großen Projekt auch eine MwSt-Tabelle eingeführt, ganz trivial:
1 - 19%
2 - 7%
In den DSätzen wurden also je nach MwSt 1 oder 2 eingetragen und mit den dazugehörigen Sätzen gerechnet.
Dann kam Corona (16%) die ganze Datenbank musste ich anpassen .... aber es war Super Einfach:
1 - 19%
2 - 7%
3 - 16%
Jetzt konnte man einfach auch die '3' bentzen um den damit verknüpften Wert weiter zu verwenden, also 16%.
Keine weitere Formel musste geändert werden ... die Fa. hat sich gefreut.
Aber meine 'Weitsicht' hat dazu gefürht, dass ich keinen weiteren Cent gesehen habe...
... oder auch wenn man seine Arbeit, weil man eben doch ein wenig Wissen hat, relativ 'schnell' sauber durchführt ...
den Kunden freut es ...
Aber ich schweif ab.
Hier ein Beispielder Verknüpfungen:
N'8 BM
Deine Kunden Tabelle ist iO:
Jedem Kunde wurde eine Kundennummer zugeordnet, das ist der Primäre Schlüssel
Die Tabelle bleibt so
Deine 2. Tabellen Telefon/E-Mail hätte ich anderst integriert:
Definiere doch einfach mögliche Kommunikationstypen, hier lt Deinen Vorgaben auch hier als Primärschlüssel:
1- Privat
2- Mobil1
3- Mobil2
4- E-Mail Geschäftlich
5- E-Mail Privat
Jetzt füllst Du eine weitere, die 3. Tabelle wie folgt:
- Die Kombination von Kundennummer (Primärschlüsel) und Kommunikationstyp (Primärschlüssel) führt zu einem eindeutigem Datensatzinhalt bezüglich der Kommunikation (Beispiel für Kunde mit Nr1...usw):
- 1- 1 - 040/110112
- 1- 2 - 0170/12356789
- 1- 4 - mm@meier.de
- 1- 5 - max@meier.de
- 2 -1 - 030/1234987
- 3 -5 - Schmitz@renate.de
usw.....
Die Zuordnung der DS-Inhalte ist durch die Kombination der 2 Schlüssel eindeutig möglich.
Erweiterungen, mehr Tel-Nr/Mail-Adressen, kannst Du durch erweitern der Tabelle 2 einfach gestalten.
Die Antwort Deines Dozenten kann ich so erst mal nicht nachvollziehen ...
Und was meinst DU?
Ich schaue hier gerade auf eine meiner besseren Leistungen in Access ... die Beziehungen einer größeren Anwendung
und will Dir noch mal einen Gedankenhinweis/-anstoß geben:
In weiser Vorausicht hatte ich schon bei der Planung in einem großen Projekt auch eine MwSt-Tabelle eingeführt, ganz trivial:
1 - 19%
2 - 7%
In den DSätzen wurden also je nach MwSt 1 oder 2 eingetragen und mit den dazugehörigen Sätzen gerechnet.
Dann kam Corona (16%) die ganze Datenbank musste ich anpassen .... aber es war Super Einfach:
1 - 19%
2 - 7%
3 - 16%
Jetzt konnte man einfach auch die '3' bentzen um den damit verknüpften Wert weiter zu verwenden, also 16%.
Keine weitere Formel musste geändert werden ... die Fa. hat sich gefreut.
Aber meine 'Weitsicht' hat dazu gefürht, dass ich keinen weiteren Cent gesehen habe...
... oder auch wenn man seine Arbeit, weil man eben doch ein wenig Wissen hat, relativ 'schnell' sauber durchführt ...
den Kunden freut es ...
Aber ich schweif ab.
Hier ein Beispielder Verknüpfungen:
N'8 BM
Ja vielen lieben Dank, das leuchtet soweit ein, wie ihr es hier sehr ausführlich dargestellt habt.
Anhand der reinen Aufgabenstellung bin ich davon ausgegangen, dass die vorhandenen Daten normalisiert werden sollen, also quasi kein Typ, oder ähnliches, hinzugefügt werden soll (es sind ja zusätzliche Datenfelder dafür nötig), von daher bin ich auf meine Lösung gekommen.
Die Lösung von Blackmann gefällt mir da am Besten, da dabei durch die Kombinatorik nur 3 Tabellen verwendet werden.
Es bleibt noch die Frage offen, ob durch das Hinzufügen des Typs die Richtlinien für die Normalisierung dennoch erfüllt werden, wobei ja nicht explizit angegeben wurde, in welcher Form (2., 3. ?) das Ergebnis normalisiert werden soll und auch kein Hinweis gegeben wurde, dass man Datentypen verwenden darf.
Blackmann schrieb:
"Die Antwort Deines Dozenten kann ich so erst mal nicht nachvollziehen ...
Und was meinst DU?"
Das ist ja genau dass, was mich dabei verwundert.
Hätte er mir das so erklärt (in Kombination mit der Verwendung von Datentypen), dann wäre mir das klar geworden, aber vielleicht liegt es auch nur an der unpräzisen Aufgabenstellung?
Fakt dürfte jedoch sein, dass seine Lösung bei Abfragen keine eindeutigen Ergebnisse liefern würde, wenn ich sie so wie er meinte umsetzen würde, also die Normalisierung niht korrekt durchgeführt worden wäre.
Meine Lösung müsste dagegen aber richtige Ergebnisse liefern können, auch wenn die mögliche Anzahl je Kunde eingeschränkt wäre (es geht ja um B2C und nicht um B2B - ergo spielt die DSGVO da ja auch eine Rolle), was die Sinnhaftigkeit von der Verwendung einer möglichen Erweiterbarkeit in Frage stellen dürfte.
Ist da ein Abzug von 8/30 Pkt. gerechtfertigt, wenn die Erweiterbarkeit nicht erwähnt wurde, meine Lösung aber ansonsten ja den Vorgaben entspricht?
LG
Anhand der reinen Aufgabenstellung bin ich davon ausgegangen, dass die vorhandenen Daten normalisiert werden sollen, also quasi kein Typ, oder ähnliches, hinzugefügt werden soll (es sind ja zusätzliche Datenfelder dafür nötig), von daher bin ich auf meine Lösung gekommen.
Die Lösung von Blackmann gefällt mir da am Besten, da dabei durch die Kombinatorik nur 3 Tabellen verwendet werden.
Es bleibt noch die Frage offen, ob durch das Hinzufügen des Typs die Richtlinien für die Normalisierung dennoch erfüllt werden, wobei ja nicht explizit angegeben wurde, in welcher Form (2., 3. ?) das Ergebnis normalisiert werden soll und auch kein Hinweis gegeben wurde, dass man Datentypen verwenden darf.
Blackmann schrieb:
"Die Antwort Deines Dozenten kann ich so erst mal nicht nachvollziehen ...
Und was meinst DU?"
Das ist ja genau dass, was mich dabei verwundert.
Hätte er mir das so erklärt (in Kombination mit der Verwendung von Datentypen), dann wäre mir das klar geworden, aber vielleicht liegt es auch nur an der unpräzisen Aufgabenstellung?
Fakt dürfte jedoch sein, dass seine Lösung bei Abfragen keine eindeutigen Ergebnisse liefern würde, wenn ich sie so wie er meinte umsetzen würde, also die Normalisierung niht korrekt durchgeführt worden wäre.
Meine Lösung müsste dagegen aber richtige Ergebnisse liefern können, auch wenn die mögliche Anzahl je Kunde eingeschränkt wäre (es geht ja um B2C und nicht um B2B - ergo spielt die DSGVO da ja auch eine Rolle), was die Sinnhaftigkeit von der Verwendung einer möglichen Erweiterbarkeit in Frage stellen dürfte.
Ist da ein Abzug von 8/30 Pkt. gerechtfertigt, wenn die Erweiterbarkeit nicht erwähnt wurde, meine Lösung aber ansonsten ja den Vorgaben entspricht?
LG
Dazu kann man viele Meinungen haben. Ich finde die vom LordGurke ganz passend. Die Adresstypes kann man auch in eine Relation bringen und so Speicherplatz und Performance auf Dauer erzielen. Fiktiv, dass die Tabelle mal über 80 Millionen Bundesbürger enthält.
Ich hätte ihn gefragt, was de Mist mit den Telefonnummern soll. Führende Null mag ja noch gehen, aber eine Schrägstrich? Welcher Datentyp soll denn dafür optimal sein? String?
Ich hätte ihn gefragt, was de Mist mit den Telefonnummern soll. Führende Null mag ja noch gehen, aber eine Schrägstrich? Welcher Datentyp soll denn dafür optimal sein? String?
Nun - alleine schon der erste Teil der Antwort sollte dir nunmal zu denken geben. Du hast 2 Telefonnummern vorgesehen. Ich habe aber schon mindestens 5 ... (Dank Telekom-Internet mit Telefon 3x Festnetz, Privat Mobil, Firma Mobil). Wenns ganz blöd läuft hast du eben auch mal 5000 weil das dein Telefonverzeichnis deines Hauptkunden ist... Jetzt merkst du schon - mit vordefinierten Feldern hast du damit also verloren.
Das mit den Lücken ist zwar heute praktisch fast (!) egal, ist aber dennoch ein durchaus richtiges Argument. Denn: Stell dir einfach mal vor ich nehme die 5000 Felder von oben, mache aus jedem nen LongText/Blob/irgendwas richtig grosses... Jetzt hast du bei den meisten Personen aber nur 1-2 Nummern - trotzdem reserviert deine Datenbank ja entsprechenden Speicher weil die eben davon ausgehen muss das dort noch Daten kommen. Man könnte es sogar etwas "pauschalisieren": Du hast heute eben nicht MSSQL,... die da schon optimieren, sondern du hattest langweile und dir dein eigenes System gebaut. Das reserviert ggf. dann eben wirklich den vollen Speicher weil der Programmierer meinte das wäre ja viel besser (spart schließlich etwas Zeit bei der Festplatte). Jetzt bist du mit leeren Feldern sozusagen am Ar....
Ob ein Abzug von 8/30 Punkten gerechtfertigt ist? Nun, das hängt von eurem Unterricht ab. Es gibt ja hier _diverse_ Lösungsansätze. Denn zum einen kannst du in der Tabelle "Telefonnummer" natürlich den Kunden verlinken. Das hat aber auch den Nachteil das wenn du zB. einen Kunden hast der ne Zentrale hat aber du dort 5 Kontakte hast -> dann hast du dieselbe Nummer 5x in der Telefonnummer-Tabelle... Damit stehst du wieder davor das du doppelte Daten hast... Man kann das also beliebig weit sehen - und damit wären dann sogar 0 von 30 Punkte ok (weil eben aufgabe nicht wirklich erfüllt) - oder man sieht das als "Teilerfüllt". Das ist zum einen Ermessenssache vom Lehrer UND abhängig von eurem Unterricht...
Das mit den Lücken ist zwar heute praktisch fast (!) egal, ist aber dennoch ein durchaus richtiges Argument. Denn: Stell dir einfach mal vor ich nehme die 5000 Felder von oben, mache aus jedem nen LongText/Blob/irgendwas richtig grosses... Jetzt hast du bei den meisten Personen aber nur 1-2 Nummern - trotzdem reserviert deine Datenbank ja entsprechenden Speicher weil die eben davon ausgehen muss das dort noch Daten kommen. Man könnte es sogar etwas "pauschalisieren": Du hast heute eben nicht MSSQL,... die da schon optimieren, sondern du hattest langweile und dir dein eigenes System gebaut. Das reserviert ggf. dann eben wirklich den vollen Speicher weil der Programmierer meinte das wäre ja viel besser (spart schließlich etwas Zeit bei der Festplatte). Jetzt bist du mit leeren Feldern sozusagen am Ar....
Ob ein Abzug von 8/30 Punkten gerechtfertigt ist? Nun, das hängt von eurem Unterricht ab. Es gibt ja hier _diverse_ Lösungsansätze. Denn zum einen kannst du in der Tabelle "Telefonnummer" natürlich den Kunden verlinken. Das hat aber auch den Nachteil das wenn du zB. einen Kunden hast der ne Zentrale hat aber du dort 5 Kontakte hast -> dann hast du dieselbe Nummer 5x in der Telefonnummer-Tabelle... Damit stehst du wieder davor das du doppelte Daten hast... Man kann das also beliebig weit sehen - und damit wären dann sogar 0 von 30 Punkte ok (weil eben aufgabe nicht wirklich erfüllt) - oder man sieht das als "Teilerfüllt". Das ist zum einen Ermessenssache vom Lehrer UND abhängig von eurem Unterricht...
1
Gab es da nicht einen entscheidenden Unterschied zwischen Theorie und Praxis?
Ich hatte mal mit einer Datenbank zu tun (einer mittelständischen, global agierenden Firma) in deren Datenbank wohl offensichtlich direkt manipuliert wurde und dadurch bei einigen Datensätzen mal CR, mal LF und auch CR und LF verendet wurden, was bei Abfragen (ich sollte dafür eine eine Outlook-Adressliste und eine Telefonliste für die Telefonanlage automatisiert erstellen lassen, wodurch mir das aufgefallen war) zu Fehlern führt.
Noch viel schlimmer war, dass die Telefonnummern nicht eindeutig hinterlegt waren und ebenfalls mit diversen Trennzeichen, teils mit Landes- und internationalen Vorwahlen und manchmal komplett ohne (für das regionale Netz) versehen waren, wo ich erstmal die eingelesenen Daten entsprechend aufbereiten musste, indem ich die Datenbankfehler im Programm korrigieren musste - also es geht noch schlimmer und es hat mich einiges an Stunden Mehrarbeit gekostet.
Da fragt man sich dann, was für Mitarbeiter in dem Unternehmen arbeiten, wenn denen die direkte Datenmanipulation und die Folgen davon nicht bewusst sind ... oh, oh, da möchte ich nicht wissen, was da noch alles schief geht.
Ich hatte mal mit einer Datenbank zu tun (einer mittelständischen, global agierenden Firma) in deren Datenbank wohl offensichtlich direkt manipuliert wurde und dadurch bei einigen Datensätzen mal CR, mal LF und auch CR und LF verendet wurden, was bei Abfragen (ich sollte dafür eine eine Outlook-Adressliste und eine Telefonliste für die Telefonanlage automatisiert erstellen lassen, wodurch mir das aufgefallen war) zu Fehlern führt.
Noch viel schlimmer war, dass die Telefonnummern nicht eindeutig hinterlegt waren und ebenfalls mit diversen Trennzeichen, teils mit Landes- und internationalen Vorwahlen und manchmal komplett ohne (für das regionale Netz) versehen waren, wo ich erstmal die eingelesenen Daten entsprechend aufbereiten musste, indem ich die Datenbankfehler im Programm korrigieren musste - also es geht noch schlimmer und es hat mich einiges an Stunden Mehrarbeit gekostet.
Da fragt man sich dann, was für Mitarbeiter in dem Unternehmen arbeiten, wenn denen die direkte Datenmanipulation und die Folgen davon nicht bewusst sind ... oh, oh, da möchte ich nicht wissen, was da noch alles schief geht.
Zitat von @8585324113:
Dazu kann man viele Meinungen haben. Ich finde die vom LordGurke ganz passend. Die Adresstypes kann man auch in eine Relation bringen und so Speicherplatz und Performance auf Dauer erzielen. Fiktiv, dass die Tabelle mal über 80 Millionen Bundesbürger enthält.
Ich hätte ihn gefragt, was de Mist mit den Telefonnummern soll. Führende Null mag ja noch gehen, aber eine Schrägstrich? Welcher Datentyp soll denn dafür optimal sein? String?
Dazu kann man viele Meinungen haben. Ich finde die vom LordGurke ganz passend. Die Adresstypes kann man auch in eine Relation bringen und so Speicherplatz und Performance auf Dauer erzielen. Fiktiv, dass die Tabelle mal über 80 Millionen Bundesbürger enthält.
Ich hätte ihn gefragt, was de Mist mit den Telefonnummern soll. Führende Null mag ja noch gehen, aber eine Schrägstrich? Welcher Datentyp soll denn dafür optimal sein? String?
Naja - Schrägstrich wäre jetzt nicht..aber zB. nen + (internationale Vorwahl) wäre eins der Sonderzeichen die durchaus berechtigt wären und auch von jedem halbwegs aktuellen Telefon akzeptiert werden würden (mir ist zB. schon seid Jahren kein Telefon untergekommen was nicht +49 oder +1 statt 0049 usw. akzeptiert hätte). Das + wird dabei gerne genommen um zu zeigen das es eine internationale Nummer ist und nicht ne Ortsvorwahl bei dem die Person nur ne 0 zuviel genommen hatte...
Zitat von @Tomtom33:
Gab es da nicht einen entscheidenden Unterschied zwischen Theorie und Praxis?
Ich hatte mal mit einer Datenbank zu tun (einer mittelständischen, global agierenden Firma) in deren Datenbank wohl offensichtlich direkt manipuliert wurde und dadurch bei einigen Datensätzen mal CR, mal LF und auch CR und LF verendet wurden, was bei Abfragen (ich sollte dafür eine eine Outlook-Adressliste und eine Telefonliste für die Telefonanlage automatisiert erstellen lassen, wodurch mir das aufgefallen war) zu Fehlern führt.
Noch viel schlimmer war, dass die Telefonnummern nicht eindeutig hinterlegt waren und ebenfalls mit diversen Trennzeichen, teils mit Landes- und internationalen Vorwahlen und manchmal komplett ohne (für das regionale Netz) versehen waren, wo ich erstmal die eingelesenen Daten entsprechend aufbereiten musste, indem ich die Datenbankfehler im Programm korrigieren musste - also es geht noch schlimmer und es hat mich einiges an Stunden Mehrarbeit gekostet.
Da fragt man sich dann, was für Mitarbeiter in dem Unternehmen arbeiten, wenn denen die direkte Datenmanipulation und die Folgen davon nicht bewusst sind ... oh, oh, da möchte ich nicht wissen, was da noch alles schief geht.
Gab es da nicht einen entscheidenden Unterschied zwischen Theorie und Praxis?
Ich hatte mal mit einer Datenbank zu tun (einer mittelständischen, global agierenden Firma) in deren Datenbank wohl offensichtlich direkt manipuliert wurde und dadurch bei einigen Datensätzen mal CR, mal LF und auch CR und LF verendet wurden, was bei Abfragen (ich sollte dafür eine eine Outlook-Adressliste und eine Telefonliste für die Telefonanlage automatisiert erstellen lassen, wodurch mir das aufgefallen war) zu Fehlern führt.
Noch viel schlimmer war, dass die Telefonnummern nicht eindeutig hinterlegt waren und ebenfalls mit diversen Trennzeichen, teils mit Landes- und internationalen Vorwahlen und manchmal komplett ohne (für das regionale Netz) versehen waren, wo ich erstmal die eingelesenen Daten entsprechend aufbereiten musste, indem ich die Datenbankfehler im Programm korrigieren musste - also es geht noch schlimmer und es hat mich einiges an Stunden Mehrarbeit gekostet.
Da fragt man sich dann, was für Mitarbeiter in dem Unternehmen arbeiten, wenn denen die direkte Datenmanipulation und die Folgen davon nicht bewusst sind ... oh, oh, da möchte ich nicht wissen, was da noch alles schief geht.
Natürlich ist es ein Unterschied zwischen Theorie und Praxis. Nur: DAS ist keine Begrüundung ob nun nen Abzug ok ist oder nicht. In der PRAXIS kann es ja sein das du nen 1-Mann-Kleinbetrieb bist und somit deine "Datenbank" in ner Excel-File oder ggf. sogar nur im Telefonspeicher hast... Mir hat man im Studium zB. mal am Anfang klar gesagt: 80-90% von dem was Sie hier lernen werden Sie später nie wieder brauchen. Leider wissen wir nicht welche 10-20% Sie in IHREM Job später brauchen also müssen Sie alles lernen.. Woher soll also dein Dozent wissen was du später machst? Wie soll er/sie/es neutral bewerten bei 30 Leuten? DU machst das ggf. nur weils grad vom Arbeitsamt angeboten wurde, dein Kollege neben dir will sich als Entwickler selbstständig machen und die 3te Person sitzt nur im Raum weils warm is aber will nich mal bestehen...
Und du wirst natürlich einen Unterschied finden. Du kannst zB. statt einer nummerischen ID auch einfach ne GUID bilden (vgl. deine SSID bei Windows Usern). DAS erfüllt wieder das Kriterium "eindeutig zuzuordnen" (sofern die richtig gebildet wird). Warum macht man das also nicht standardmässig? Weil ne Datenbank mit mehreren millionen u. mehr Einträgen damit ggf. sehr träge wird wenn man da Vergleiche zwischen 2+ Tabellen durchführt (da es auf CPU Ebene eben nen deutlich komplexerer Vergleich ist als ne einfache Subtraktion von zwei Zahlen). Dafür ist die GUID eben prinzipiell nahezu unbegrenzt während dein Auto-Increment-Wert eben irgendwo ein "natürliches" Ende hat... Du siehst, auch da gibt es durchaus unterschiedliche Wege die beide nicht pauschal richtig oder falsch sind sondern einfach von der Anwendung abhängen... und es ist nicht unüblich das du in einer DB beides findest ;)
1Zitat von @maretz:
Nun - alleine schon der erste Teil der Antwort sollte dir nunmal zu denken geben. Du hast 2 Telefonnummern vorgesehen. Ich habe aber schon mindestens 5 ... (Dank Telekom-Internet mit Telefon 3x Festnetz, Privat Mobil, Firma Mobil). Wenns ganz blöd läuft hast du eben auch mal 5000 weil das dein Telefonverzeichnis deines Hauptkunden ist... Jetzt merkst du schon - mit vordefinierten Feldern hast du damit also verloren.
Nun - alleine schon der erste Teil der Antwort sollte dir nunmal zu denken geben. Du hast 2 Telefonnummern vorgesehen. Ich habe aber schon mindestens 5 ... (Dank Telekom-Internet mit Telefon 3x Festnetz, Privat Mobil, Firma Mobil). Wenns ganz blöd läuft hast du eben auch mal 5000 weil das dein Telefonverzeichnis deines Hauptkunden ist... Jetzt merkst du schon - mit vordefinierten Feldern hast du damit also verloren.
Sicherlich ist das richtig, nur welche Firma speichert bei Kundendaten im B2C-Bereich mehr Nummern und sammelt diese, was laut DSGVO wohl eher problematisch wäre?
Im B2B-Bereich leuchtet es jedoch ein, nur davon war in der Aufgabenstellung aber nicht die Rede.
Das mit den Lücken ist zwar heute praktisch fast (!) egal, ist aber dennoch ein durchaus richtiges Argument. Denn: Stell dir einfach mal vor ich nehme die 5000 Felder von oben, mache aus jedem nen LongText/Blob/irgendwas richtig grosses... Jetzt hast du bei den meisten Personen aber nur 1-2 Nummern - trotzdem reserviert deine Datenbank ja entsprechenden Speicher weil die eben davon ausgehen muss das dort noch Daten kommen. Man könnte es sogar etwas "pauschalisieren": Du hast heute eben nicht MSSQL,... die da schon optimieren, sondern du hattest langweile und dir dein eigenes System gebaut. Das reserviert ggf. dann eben wirklich den vollen Speicher weil der Programmierer meinte das wäre ja viel besser (spart schließlich etwas Zeit bei der Festplatte). Jetzt bist du mit leeren Feldern sozusagen am Ar....
ok, das hört sich plausibel an, nur welche Datenbank arbeitet heute noch ohne Optimierung und reserviert dafür Speicher, wenn kein Wert eingetragen ist?
Ob ein Abzug von 8/30 Punkten gerechtfertigt ist? Nun, das hängt von eurem Unterricht ab. Es gibt ja hier _diverse_ Lösungsansätze. Denn zum einen kannst du in der Tabelle "Telefonnummer" natürlich den Kunden verlinken. Das hat aber auch den Nachteil das wenn du zB. einen Kunden hast der ne Zentrale hat aber du dort 5 Kontakte hast -> dann hast du dieselbe Nummer 5x in der Telefonnummer-Tabelle... Damit stehst du wieder davor das du doppelte Daten hast... Man kann das also beliebig weit sehen - und damit wären dann sogar 0 von 30 Punkte ok (weil eben aufgabe nicht wirklich erfüllt) - oder man sieht das als "Teilerfüllt". Das ist zum einen Ermessenssache vom Lehrer UND abhängig von eurem Unterricht...
Diesen Fall (mit den Nummern der Zentrale) hättest Du ja auch in den Lösungen der anderen und eine Nummer einer Zentrale müsste dann über die Firma definiert werden, wobei dann nur Durchwahlen gespeichert werden und die Nummer der zentral dann einspringt, wenn für den MA keine Durchwahl hinterlegt wurde, nur auch das wäre B2B und nicht B2C.
Sicherlich hängt es vom Unterricht ab und der Einschätzung des Dozenten ab, nur beantwortet es nicht die eigentliche Frage, nämlich ob es bei einer Normalisierung erlaubt ist, einfach so Datentypen zu verwenden, wenn diese nicht vorgesehen sind und ja auch nicht gefordert sind.
Aber dennoch Danke für deine Antwort.
Ich gebe deinem Dozenten auch recht. Bei den Details schliesse ich mich den Vorrednern an.
Trotzdem gebe ich meinen Senf auch noch gern dazu versuche aber eine neue Perspektive
Denn genau das ist wirklich wichtig beim Design von Datenbanken, wird aber oft von Unerfahrenen unterschätzt.
Die Theorie und die Praxis klaffen meist dann auseinander, wenn jemand versucht die Datenbank für dem Menschen leserlich zu gestalten.
Eine Tabelle, die aussieht wie ein Excel-Sheet ist besser "human-readable" als eine normalisierte Datenbank mit vielen Tabellen und damit verbundenen Fremdschlüsselbeziehungen.
Eine Datenbank wird aber üblicherweise nicht von einem Menschen direkt bearbeitet, sondern ein Programm schreibt die Daten rein und ein Programm liest die Daten wieder raus. Hier kommt es drauf an, dass man die Daten effizient verarbeiten kann und nicht wie sie aussehen.
Die Diskussion über Indexe für die Performance lass ich hier mal weg.
Eine der Herausforderungen (meint, damit tun sich viele Unerfahrene schwer) bei Datenbanken (zumindest bei SQL) ist der JOIN.
Sobald man richtig normalisiert, braucht man JOINs und die sind auf einer normalisierten Datenbank viel einfacher zu formulieren als auf einer nicht normalisierten.
Zusätzlich sind normalisierte Datenbanken viel einfacher zu erweitern.
Stell dir vor es müssen die Daten einer Person mit 3 oder ganz extrem 100 (Mobil) Telefonnummern in die Datenbank eingetragen werden.
In deiner Aufteilung musst du dafür die Tabelle "Telefon" erweitern, in der normalisierten Datenbank geht das auch so.
Da es hier um "kleine" Datenmengen geht, kann man das alles noch irgendwie hinbiegen. Aber beim Design weisst du ja nicht, wie "gross" die Datenmengen schlussendlich werden.
In der Wissenschaft (Informatik) ist Normalisierung auch dazu da, um Datenbanken zu vergleichen, d.h. die Frage zu beantworten "Ist diese Datenbank identisch mit dieser Datenbank?"
Aber da würde ich nun abschweifen und ich denke nicht, dass das hier jemand interessiert.
Trotzdem gebe ich meinen Senf auch noch gern dazu versuche aber eine neue Perspektive
Denn genau das ist wirklich wichtig beim Design von Datenbanken, wird aber oft von Unerfahrenen unterschätzt.
Die Theorie und die Praxis klaffen meist dann auseinander, wenn jemand versucht die Datenbank für dem Menschen leserlich zu gestalten.
Eine Tabelle, die aussieht wie ein Excel-Sheet ist besser "human-readable" als eine normalisierte Datenbank mit vielen Tabellen und damit verbundenen Fremdschlüsselbeziehungen.
Eine Datenbank wird aber üblicherweise nicht von einem Menschen direkt bearbeitet, sondern ein Programm schreibt die Daten rein und ein Programm liest die Daten wieder raus. Hier kommt es drauf an, dass man die Daten effizient verarbeiten kann und nicht wie sie aussehen.
Die Diskussion über Indexe für die Performance lass ich hier mal weg.
Eine der Herausforderungen (meint, damit tun sich viele Unerfahrene schwer) bei Datenbanken (zumindest bei SQL) ist der JOIN.
Sobald man richtig normalisiert, braucht man JOINs und die sind auf einer normalisierten Datenbank viel einfacher zu formulieren als auf einer nicht normalisierten.
Zusätzlich sind normalisierte Datenbanken viel einfacher zu erweitern.
Stell dir vor es müssen die Daten einer Person mit 3 oder ganz extrem 100 (Mobil) Telefonnummern in die Datenbank eingetragen werden.
In deiner Aufteilung musst du dafür die Tabelle "Telefon" erweitern, in der normalisierten Datenbank geht das auch so.
Da es hier um "kleine" Datenmengen geht, kann man das alles noch irgendwie hinbiegen. Aber beim Design weisst du ja nicht, wie "gross" die Datenmengen schlussendlich werden.
In der Wissenschaft (Informatik) ist Normalisierung auch dazu da, um Datenbanken zu vergleichen, d.h. die Frage zu beantworten "Ist diese Datenbank identisch mit dieser Datenbank?"
Aber da würde ich nun abschweifen und ich denke nicht, dass das hier jemand interessiert.
Moin @Tomtom33,
ich muss deinem Dozenten leider auch recht geben.
Meine Lösung würde z.B. folgend aussehen.
RELPERSON
|PID|LNAME|FNAME|
|-|-|-|
|1|Meier|Max|
|2|Müller|Erwin|
|3|Schmitz|Renate|
RELCONTACTTYPE
|CTID|TYPE|
|-|-|
|1|Festnetz|
|2|Handy|
|3|E-Mail|
RELCONTACT
|CID|PID|CTID|CONTACT|
|-|-|-|-|
|1|1|1|040/110112|
|2|1|2|0170/123456789|
|3|1|3|mm@meier.de|
|4|1|3|max@meier.de|
|5|2|1|030/1234987|
|6|2|2|0171/987654321|
|7|2|2|0175/123456789|
|8|3|1|0234/1122222|
|9|3|3|schmitz@renate.de|
Gruss Alex
Und die Antwort des Dozenten:
"Ich würde die Telefonnummer und E-Mailadresse für jeden Eintrag in einem eigenen Datensatz speichern. Dann entstehen zum einen keine Lücken wie bei den Einträgen 1 und 3 bei der Telefonnummer. Zum anderen könnten Sie auch problemlos mehr als 3 Einträge für die Telefonnummer beziehungsweise mehr als 2 Einträge für die E-Mail-Adresse speichern."
Dafür hat er mir nur 22/30 Pkt. gegeben.
"Ich würde die Telefonnummer und E-Mailadresse für jeden Eintrag in einem eigenen Datensatz speichern. Dann entstehen zum einen keine Lücken wie bei den Einträgen 1 und 3 bei der Telefonnummer. Zum anderen könnten Sie auch problemlos mehr als 3 Einträge für die Telefonnummer beziehungsweise mehr als 2 Einträge für die E-Mail-Adresse speichern."
Dafür hat er mir nur 22/30 Pkt. gegeben.
ich muss deinem Dozenten leider auch recht geben.
Meine Lösung würde z.B. folgend aussehen.
RELPERSON
|PID|LNAME|FNAME|
|-|-|-|
|1|Meier|Max|
|2|Müller|Erwin|
|3|Schmitz|Renate|
RELCONTACTTYPE
|CTID|TYPE|
|-|-|
|1|Festnetz|
|2|Handy|
|3|E-Mail|
RELCONTACT
|CID|PID|CTID|CONTACT|
|-|-|-|-|
|1|1|1|040/110112|
|2|1|2|0170/123456789|
|3|1|3|mm@meier.de|
|4|1|3|max@meier.de|
|5|2|1|030/1234987|
|6|2|2|0171/987654321|
|7|2|2|0175/123456789|
|8|3|1|0234/1122222|
|9|3|3|schmitz@renate.de|
Gruss Alex
Zitat von @maretz:
Natürlich ist es ein Unterschied zwischen Theorie und Praxis. Nur: DAS ist keine Begrüundung ob nun nen Abzug ok ist oder nicht. In der PRAXIS kann es ja sein das du nen 1-Mann-Kleinbetrieb bist und somit deine "Datenbank" in ner Excel-File oder ggf. sogar nur im Telefonspeicher hast... Mir hat man im Studium zB. mal am Anfang klar gesagt: 80-90% von dem was Sie hier lernen werden Sie später nie wieder brauchen. Leider wissen wir nicht welche 10-20% Sie in IHREM Job später brauchen also müssen Sie alles lernen.. Woher soll also dein Dozent wissen was du später machst? Wie soll er/sie/es neutral bewerten bei 30 Leuten? DU machst das ggf. nur weils grad vom Arbeitsamt angeboten wurde, dein Kollege neben dir will sich als Entwickler selbstständig machen und die 3te Person sitzt nur im Raum weils warm is aber will nich mal bestehen...
Natürlich hängt es sehr stark davon ab, was man später damit anstellt und klar, man benötigt später nur einen Bruchteil von dem, was man so alles erlernt hat.Zitat von @Tomtom33:
Gab es da nicht einen entscheidenden Unterschied zwischen Theorie und Praxis?
Ich hatte mal mit einer Datenbank zu tun (einer mittelständischen, global agierenden Firma) in deren Datenbank wohl offensichtlich direkt manipuliert wurde und dadurch bei einigen Datensätzen mal CR, mal LF und auch CR und LF verendet wurden, was bei Abfragen (ich sollte dafür eine eine Outlook-Adressliste und eine Telefonliste für die Telefonanlage automatisiert erstellen lassen, wodurch mir das aufgefallen war) zu Fehlern führt.
Noch viel schlimmer war, dass die Telefonnummern nicht eindeutig hinterlegt waren und ebenfalls mit diversen Trennzeichen, teils mit Landes- und internationalen Vorwahlen und manchmal komplett ohne (für das regionale Netz) versehen waren, wo ich erstmal die eingelesenen Daten entsprechend aufbereiten musste, indem ich die Datenbankfehler im Programm korrigieren musste - also es geht noch schlimmer und es hat mich einiges an Stunden Mehrarbeit gekostet.
Da fragt man sich dann, was für Mitarbeiter in dem Unternehmen arbeiten, wenn denen die direkte Datenmanipulation und die Folgen davon nicht bewusst sind ... oh, oh, da möchte ich nicht wissen, was da noch alles schief geht.
Gab es da nicht einen entscheidenden Unterschied zwischen Theorie und Praxis?
Ich hatte mal mit einer Datenbank zu tun (einer mittelständischen, global agierenden Firma) in deren Datenbank wohl offensichtlich direkt manipuliert wurde und dadurch bei einigen Datensätzen mal CR, mal LF und auch CR und LF verendet wurden, was bei Abfragen (ich sollte dafür eine eine Outlook-Adressliste und eine Telefonliste für die Telefonanlage automatisiert erstellen lassen, wodurch mir das aufgefallen war) zu Fehlern führt.
Noch viel schlimmer war, dass die Telefonnummern nicht eindeutig hinterlegt waren und ebenfalls mit diversen Trennzeichen, teils mit Landes- und internationalen Vorwahlen und manchmal komplett ohne (für das regionale Netz) versehen waren, wo ich erstmal die eingelesenen Daten entsprechend aufbereiten musste, indem ich die Datenbankfehler im Programm korrigieren musste - also es geht noch schlimmer und es hat mich einiges an Stunden Mehrarbeit gekostet.
Da fragt man sich dann, was für Mitarbeiter in dem Unternehmen arbeiten, wenn denen die direkte Datenmanipulation und die Folgen davon nicht bewusst sind ... oh, oh, da möchte ich nicht wissen, was da noch alles schief geht.
Natürlich ist es ein Unterschied zwischen Theorie und Praxis. Nur: DAS ist keine Begrüundung ob nun nen Abzug ok ist oder nicht. In der PRAXIS kann es ja sein das du nen 1-Mann-Kleinbetrieb bist und somit deine "Datenbank" in ner Excel-File oder ggf. sogar nur im Telefonspeicher hast... Mir hat man im Studium zB. mal am Anfang klar gesagt: 80-90% von dem was Sie hier lernen werden Sie später nie wieder brauchen. Leider wissen wir nicht welche 10-20% Sie in IHREM Job später brauchen also müssen Sie alles lernen.. Woher soll also dein Dozent wissen was du später machst? Wie soll er/sie/es neutral bewerten bei 30 Leuten? DU machst das ggf. nur weils grad vom Arbeitsamt angeboten wurde, dein Kollege neben dir will sich als Entwickler selbstständig machen und die 3te Person sitzt nur im Raum weils warm is aber will nich mal bestehen...
Nur ist es schon so, dass der Dozent weiß in welche Richtung das geht, nämlich in die Programmierung (in dem Fall Python und Java), denn da liegt der Fokus und auch für Python ist er der Fachdozent.
Und du wirst natürlich einen Unterschied finden. Du kannst zB. statt einer nummerischen ID auch einfach ne GUID bilden (vgl. deine SSID bei Windows Usern). DAS erfüllt wieder das Kriterium "eindeutig zuzuordnen" (sofern die richtig gebildet wird). Warum macht man das also nicht standardmässig? Weil ne Datenbank mit mehreren millionen u. mehr Einträgen damit ggf. sehr träge wird wenn man da Vergleiche zwischen 2+ Tabellen durchführt (da es auf CPU Ebene eben nen deutlich komplexerer Vergleich ist als ne einfache Subtraktion von zwei Zahlen). Dafür ist die GUID eben prinzipiell nahezu unbegrenzt während dein Auto-Increment-Wert eben irgendwo ein "natürliches" Ende hat... Du siehst, auch da gibt es durchaus unterschiedliche Wege die beide nicht pauschal richtig oder falsch sind sondern einfach von der Anwendung abhängen... und es ist nicht unüblich das du in einer DB beides findest ;)
Eben, es hängt immer vom Anwendungsfall ab, wie man eine Datenbank aufbaut und welche Lösungswege man dafür verwendet (siehe auch B2B und B2C, die sich von den Anforderungen unterscheiden).
Hätte in der Aufgabenstellung gestanden, dass man auf die Erweiterbarkeit achten soll, wäre das ja so, oder so zu Berücksichtigen und meine Lösung damit fehlerhaft, nur das stand dort nicht als Teil der Aufgabenstellung.
Moin @Frank,
warum werden hier die Tabellen die korrekt nach Markdown formatiert sind, nicht sauber dargestellt?
Gruss Alex
warum werden hier die Tabellen die korrekt nach Markdown formatiert sind, nicht sauber dargestellt?
Gruss Alex
Zitat von @maretz:
Naja - Schrägstrich wäre jetzt nicht..aber zB. nen + (internationale Vorwahl) wäre eins der Sonderzeichen die durchaus berechtigt wären und auch von jedem halbwegs aktuellen Telefon akzeptiert werden würden (mir ist zB. schon seid Jahren kein Telefon untergekommen was nicht +49 oder +1 statt 0049 usw. akzeptiert hätte). Das + wird dabei gerne genommen um zu zeigen das es eine internationale Nummer ist und nicht ne Ortsvorwahl bei dem die Person nur ne 0 zuviel genommen hatte...
Zitat von @8585324113:
Dazu kann man viele Meinungen haben. Ich finde die vom LordGurke ganz passend. Die Adresstypes kann man auch in eine Relation bringen und so Speicherplatz und Performance auf Dauer erzielen. Fiktiv, dass die Tabelle mal über 80 Millionen Bundesbürger enthält.
Ich hätte ihn gefragt, was de Mist mit den Telefonnummern soll. Führende Null mag ja noch gehen, aber eine Schrägstrich? Welcher Datentyp soll denn dafür optimal sein? String?
Dazu kann man viele Meinungen haben. Ich finde die vom LordGurke ganz passend. Die Adresstypes kann man auch in eine Relation bringen und so Speicherplatz und Performance auf Dauer erzielen. Fiktiv, dass die Tabelle mal über 80 Millionen Bundesbürger enthält.
Ich hätte ihn gefragt, was de Mist mit den Telefonnummern soll. Führende Null mag ja noch gehen, aber eine Schrägstrich? Welcher Datentyp soll denn dafür optimal sein? String?
Naja - Schrägstrich wäre jetzt nicht..aber zB. nen + (internationale Vorwahl) wäre eins der Sonderzeichen die durchaus berechtigt wären und auch von jedem halbwegs aktuellen Telefon akzeptiert werden würden (mir ist zB. schon seid Jahren kein Telefon untergekommen was nicht +49 oder +1 statt 0049 usw. akzeptiert hätte). Das + wird dabei gerne genommen um zu zeigen das es eine internationale Nummer ist und nicht ne Ortsvorwahl bei dem die Person nur ne 0 zuviel genommen hatte...
Ich meinte dass so, dass Datenbanken/Tabellen/ Spalten die rein numerische Werte haben sich viel besser durch die DB-Engines optimieren lassen und man selbst bei Tabellen mit Milliarden Zeilen performant Ergebnisse bekommt.
So wie es keine numerischen Datentypen sind oder hochoptimierte andere (datetime2) muss man meiner Meinung nach immer darüber nachdenken.
Tabellen nach Strings durchsuchen ist doch der letzte Mist.
Zitat von @MysticFoxDE:
Moin @Tomtom33,
ich muss deinem Dozenten leider auch recht geben.
Meine Lösung würde z.B. folgend aussehen.
RELPERSON
|PID|LNAME|FNAME|
|-|-|-|
|1|Meier|Max|
|2|Müller|Erwin|
|3|Schmitz|Renate|
RELCONTACTTYPE
|CTID|TYPE|
|-|-|
|1|Festnetz|
|2|Handy|
|3|E-Mail|
RELCONTACT
|CID|PID|CTID|CONTACT|
|-|-|-|-|
|1|1|1|040/110112|
|2|1|2|0170/123456789|
|3|1|3|mm@meier.de|
|4|1|3|max@meier.de|
|5|2|1|030/1234987|
|6|2|2|0171/987654321|
|7|2|2|0175/123456789|
|8|3|1|0234/1122222|
|9|3|3|schmitz@renate.de|
Gruss Alex
Moin @Tomtom33,
Und die Antwort des Dozenten:
"Ich würde die Telefonnummer und E-Mailadresse für jeden Eintrag in einem eigenen Datensatz speichern. Dann entstehen zum einen keine Lücken wie bei den Einträgen 1 und 3 bei der Telefonnummer. Zum anderen könnten Sie auch problemlos mehr als 3 Einträge für die Telefonnummer beziehungsweise mehr als 2 Einträge für die E-Mail-Adresse speichern."
Dafür hat er mir nur 22/30 Pkt. gegeben.
"Ich würde die Telefonnummer und E-Mailadresse für jeden Eintrag in einem eigenen Datensatz speichern. Dann entstehen zum einen keine Lücken wie bei den Einträgen 1 und 3 bei der Telefonnummer. Zum anderen könnten Sie auch problemlos mehr als 3 Einträge für die Telefonnummer beziehungsweise mehr als 2 Einträge für die E-Mail-Adresse speichern."
Dafür hat er mir nur 22/30 Pkt. gegeben.
ich muss deinem Dozenten leider auch recht geben.
Meine Lösung würde z.B. folgend aussehen.
RELPERSON
|PID|LNAME|FNAME|
|-|-|-|
|1|Meier|Max|
|2|Müller|Erwin|
|3|Schmitz|Renate|
RELCONTACTTYPE
|CTID|TYPE|
|-|-|
|1|Festnetz|
|2|Handy|
|3|E-Mail|
RELCONTACT
|CID|PID|CTID|CONTACT|
|-|-|-|-|
|1|1|1|040/110112|
|2|1|2|0170/123456789|
|3|1|3|mm@meier.de|
|4|1|3|max@meier.de|
|5|2|1|030/1234987|
|6|2|2|0171/987654321|
|7|2|2|0175/123456789|
|8|3|1|0234/1122222|
|9|3|3|schmitz@renate.de|
Gruss Alex
Ja das entspricht in etwa der Lösung von Blackmann, welche ich persönlich favorisiere und genau der Problematik entgegengewirkt hätte.
Mir war dabei offensichtlich nicht bewusst, dass man bei einer Normalisierung halt auch Datenbezüge durch hinzufügen von Daten schaffen darf.
Der Sinn leuchtet mir aber jetzt ein, was ich allerdings anhand des Kommentars des Dozenten so nicht nachvollziehen konnte.
Da werde ich wohl mit dem Punktabzug leben müssen und danke euch für eure Antworten und Meinungen.
LG
1
Moin @Tomtom33,
vielleicht tröstet dich das ja ein bisschen.
Soeben erreicht mich eine Mail von Intel, laut der angeblich die Garantie Erweiterung für zwei von uns erworbenen !! DUAL PROCESSOR !! NUC10I5FNH wohl ausgelaufen währe. 🙃
🤪
Sprich, selbst Intel hat seine Produkt-DB nicht wirklich zu 100% im Griff.
Gruss Alex
Da werde ich wohl mit dem Punktabzug leben müssen und danke euch für eure Antworten und Meinungen.
vielleicht tröstet dich das ja ein bisschen.
Soeben erreicht mich eine Mail von Intel, laut der angeblich die Garantie Erweiterung für zwei von uns erworbenen !! DUAL PROCESSOR !! NUC10I5FNH wohl ausgelaufen währe. 🙃
🤪
Sprich, selbst Intel hat seine Produkt-DB nicht wirklich zu 100% im Griff.
Gruss Alex
1Zitat von @ITwissen:
Ich gebe deinem Dozenten auch recht. Bei den Details schliesse ich mich den Vorrednern an.
Trotzdem gebe ich meinen Senf auch noch gern dazu versuche aber eine neue Perspektive
Denn genau das ist wirklich wichtig beim Design von Datenbanken, wird aber oft von Unerfahrenen unterschätzt.
Die Theorie und die Praxis klaffen meist dann auseinander, wenn jemand versucht die Datenbank für dem Menschen leserlich zu gestalten.
Eine Tabelle, die aussieht wie ein Excel-Sheet ist besser "human-readable" als eine normalisierte Datenbank mit vielen Tabellen und damit verbundenen Fremdschlüsselbeziehungen.
Eine Datenbank wird aber üblicherweise nicht von einem Menschen direkt bearbeitet, sondern ein Programm schreibt die Daten rein und ein Programm liest die Daten wieder raus. Hier kommt es drauf an, dass man die Daten effizient verarbeiten kann und nicht wie sie aussehen.
Die Diskussion über Indexe für die Performance lass ich hier mal weg.
Eine der Herausforderungen (meint, damit tun sich viele Unerfahrene schwer) bei Datenbanken (zumindest bei SQL) ist der JOIN.
Sobald man richtig normalisiert, braucht man JOINs und die sind auf einer normalisierten Datenbank viel einfacher zu formulieren als auf einer nicht normalisierten.
Zusätzlich sind normalisierte Datenbanken viel einfacher zu erweitern.
Stell dir vor es müssen die Daten einer Person mit 3 oder ganz extrem 100 (Mobil) Telefonnummern in die Datenbank eingetragen werden.
In deiner Aufteilung musst du dafür die Tabelle "Telefon" erweitern, in der normalisierten Datenbank geht das auch so.
Da es hier um "kleine" Datenmengen geht, kann man das alles noch irgendwie hinbiegen. Aber beim Design weisst du ja nicht, wie "gross" die Datenmengen schlussendlich werden.
In der Wissenschaft (Informatik) ist Normalisierung auch dazu da, um Datenbanken zu vergleichen, d.h. die Frage zu beantworten "Ist diese Datenbank identisch mit dieser Datenbank?"
Aber da würde ich nun abschweifen und ich denke nicht, dass das hier jemand interessiert.
Ich gebe deinem Dozenten auch recht. Bei den Details schliesse ich mich den Vorrednern an.
Trotzdem gebe ich meinen Senf auch noch gern dazu versuche aber eine neue Perspektive
Denn genau das ist wirklich wichtig beim Design von Datenbanken, wird aber oft von Unerfahrenen unterschätzt.
Die Theorie und die Praxis klaffen meist dann auseinander, wenn jemand versucht die Datenbank für dem Menschen leserlich zu gestalten.
Eine Tabelle, die aussieht wie ein Excel-Sheet ist besser "human-readable" als eine normalisierte Datenbank mit vielen Tabellen und damit verbundenen Fremdschlüsselbeziehungen.
Eine Datenbank wird aber üblicherweise nicht von einem Menschen direkt bearbeitet, sondern ein Programm schreibt die Daten rein und ein Programm liest die Daten wieder raus. Hier kommt es drauf an, dass man die Daten effizient verarbeiten kann und nicht wie sie aussehen.
Die Diskussion über Indexe für die Performance lass ich hier mal weg.
Eine der Herausforderungen (meint, damit tun sich viele Unerfahrene schwer) bei Datenbanken (zumindest bei SQL) ist der JOIN.
Sobald man richtig normalisiert, braucht man JOINs und die sind auf einer normalisierten Datenbank viel einfacher zu formulieren als auf einer nicht normalisierten.
Zusätzlich sind normalisierte Datenbanken viel einfacher zu erweitern.
Stell dir vor es müssen die Daten einer Person mit 3 oder ganz extrem 100 (Mobil) Telefonnummern in die Datenbank eingetragen werden.
In deiner Aufteilung musst du dafür die Tabelle "Telefon" erweitern, in der normalisierten Datenbank geht das auch so.
Da es hier um "kleine" Datenmengen geht, kann man das alles noch irgendwie hinbiegen. Aber beim Design weisst du ja nicht, wie "gross" die Datenmengen schlussendlich werden.
In der Wissenschaft (Informatik) ist Normalisierung auch dazu da, um Datenbanken zu vergleichen, d.h. die Frage zu beantworten "Ist diese Datenbank identisch mit dieser Datenbank?"
Aber da würde ich nun abschweifen und ich denke nicht, dass das hier jemand interessiert.
Ja die Argumente leuchten ein, das steht außer Frage, und die Performance spielt da eine große Rolle.
Mit Join und Union etc. habe ich schon gearbeitet, war ja auch Bestandteil meiner IHK-Abschlussprüfung zum Fachinformatiker für Anwendungsentwicklung, das ist nicht ganz so einfach, aber auch nicht wirklich schwer, wenn man es ein paar Mal angewendet hat, auch wenn die SQL-Anweisungen dafür recht lang ausfallen können (bei meiner damaligen Aufgabenstellung war das über eine 3/4 Seite für eine Anweisung) und ja, auch eine Aufgabenstellung zur Normalisierung kam darin vor, jedoch mit klaren Anweisungen.
Aber wie dem auch sei, ich werde wohl damit leben müssen, dass ich da offensichtlich ein paar Dinge übersehen habe und ich habe mit Sicherheit daraus gelernt.
Also vielen Dank für eure Antworten.
LG
Guten Morgen,
mir gefällt die Lösung von @Blackmann ebenfalls.
Ja die Sache mit der n-ten Normalform isst mir auch aufgefallen. Wenn es praxisnah sein soll, dann soll die Normalisierung ein Optimum heraus holen. Das wäre Stand 2023 immer noch die 3. NF oder sogar 3.5. Die 1. hast du ja locker erfüllt: Atomar und keine vielfachen Werte in einer Zelle. Du hast nur dann aufgehört.
1:1, 1:n oder m:n - hatte auch kurz gehardert ob man many-to-many bei den Typen noch unterbringen kann. @Blackmann hat die übliche Form mit beschrieben.
MwSt oder auch Skonto-Berechnung: ID, Prozent und Beschreibung.
ID: Es muss eindeutig sein! Namen sind es nicht. Auch bei den Positionen in Rechnunen kommt man nicht hin. Man kann entweder mit zusammengsetzten Schlüsseln arbeiten oder eine eindeutige Nummer selber vergeben oder als Auto-Increment. Es geht nicht anders. Man dichtet auch nichtrs hinzu. ID als unique identifier ist immer legitim. Eine UID ist es zwar auch, aber man bleibt bei der ID. Das wäre so OK.
An die Daten kommt man meist immer wieder einfach ran. Das Aufteilen in viele "komische" Tabellen sollte dich erstmal nicht stören. @LordGurke hat ja schon ein Bsp. dazu gegeben. WHERE-Part und geeignete Joins und der Groschen fällt recht schnell.
Komische Werte: Du bringst hier ein paar Dinge durcheinander. Bei DB geht es ja mehr um ref. Integrität. Man will auch Insert und Update Anomalien vermeiden. Da geht es mehr um Zuordnung der Tabellen zueinander.
Zeilenende oder Telenfonummern sind immer so eine Sache. Constraint wäre da auch schwierig. Man kann das eig. nur beim Befüllen abfangen - im Programm oder wenn mal INSERT Scripte schreibt auf den Weg.
Es gibt in Deutschland auch weniger Schreibweisen wie man denkt. ISO Vorlage mal anschauen und danach arbeiten. Zeilenende oder Tel.Nummern sind noch dankbar. Interessant wird es wenn sich die Codepage ändert. Oder auch wenn man cs hat und zwischen Groß- und Kleinschreibung unterscheidet.
Datenschrott einzutragen ist eine Sache, hat aber nichts mit der Normalisierung erstmal zu tun. Das kannst du hier esrtmal kurz ausblenden. Dennoch Daumen hoch, dass dir sowas auffällt. Genau so ein Mist kann später auch bei guten Aufbau zu Problemen führen. Nicht immer kann es durch Datentypen abfangen. TEXT ist immer noch ein schönes Format. Nimm Artikel-Nummern: die gibt es ja teils auch als Zahl-Buchstaben Kombination.
Collation und falsch gefüllte Felder machen Probleme. Sind erstmal bei INSERT und Update Anomalien zu vernachlössigen. Schlimmer ist es, wenn eine Tabelle von mehreren Tabellen nach dem Löschen die Kombi ID-Wert noch hat. Und man dann später mit der gleichen ID - gibt es ja nicht mehr - da wieder rangeht. Ist schon ein Wert drin.
Beliebt ist auch dass das Nichts oder Leere Masken-Felder die 0 haben. Hat nun jemand bei 0 eine Telefonnummer hinterlegt, so ist bei JEDEM Kunden dann auf einmal die gleiche Nummer drin.
Wie geht sowas? Indem man z.B. keinen Auto-Increment Wert hat und Anhand von Nummerkreisen selber für Eindeutigkeit sorgt. Ist in der laufenden Eingabe dann 0 mit Telefonnummer ZUNÄCHST gefüllt und es stürzt ab, hat man z.B. so ein Problem.
Der Task, der anhand des Nummerkreises eine ID holen sollte kam nicht zum Zuge. 4GL Sprache wie z.B. Magic uniPaaS und XPA können mit Dummy Werten arbeiten und am Ende wirde es weggeschrieben. KÖNNEN. mna kann aber auch direkt in die DB schreiben. Ist das Transaktions-Ende falsch hat man auf einmal bei ID 0 die Telefonnummer drin.
Hier geht es aber dann um das Befüllen bzw. die Logik dahinter. Name und Vorname sind nicht eindeutig. Eine ID sich auszudenken ist hier ein muss. Die Logik Fehler oben sind ein anderes Thema!
MwSt, Skonto und Anreden in Extra-Tabelle:
Du kannst auch hier noch einfacher Denken. Der User soll im Pulldown Menü eine Sache auswählen. Man kann alle Werte und Texte von Hand da reinschreiben. Oder man verlinkt eine Tabelle. Hier siehst du auch, dass es vollkommen ausreicht wenn diese Tabelle
So hat es @Blackmann für die Nummern-Art genmacht.
Die User sind gierig!
Wenn es was nicht gibt, wird es halt erfunden! ERP Systeme sind Teuer. "Hier unten das Feld Ref. AA Nr. ist bei uns seit 30 J leer! Da kann ich doch was rein tun, damit wir endlich eine kaufmännische Freigabe haben".
"Dieser Artikel ist ###e. Ich schreib mal ein "-S" dahinter, damit es jeder weiß."
Dann kommt ein Update und alles ist weg. Oder man hat mit "*" selektiert und oh wunder auf einmal haben wir über all Duplikate in der Ausgabe.
"Mobil-Nummer 2 hat doch kein Mensch! Wir nehmen es einfach für diese neue, komsiche Steuer-Identifikationsnummer."
Wozu auf ein Update warten? Kostet doch nur Geld. wir füllen mal und in Crystal Reports isd das Feld dcoh auch da. Hey ich hab meinen eigenen Bericht erweitert!
Merkst du was? Willkommen in der Welte der Power- und Key-User im Unternehmen.
mir gefällt die Lösung von @Blackmann ebenfalls.
Ja die Sache mit der n-ten Normalform isst mir auch aufgefallen. Wenn es praxisnah sein soll, dann soll die Normalisierung ein Optimum heraus holen. Das wäre Stand 2023 immer noch die 3. NF oder sogar 3.5. Die 1. hast du ja locker erfüllt: Atomar und keine vielfachen Werte in einer Zelle. Du hast nur dann aufgehört.
1:1, 1:n oder m:n - hatte auch kurz gehardert ob man many-to-many bei den Typen noch unterbringen kann. @Blackmann hat die übliche Form mit beschrieben.
MwSt oder auch Skonto-Berechnung: ID, Prozent und Beschreibung.
ID: Es muss eindeutig sein! Namen sind es nicht. Auch bei den Positionen in Rechnunen kommt man nicht hin. Man kann entweder mit zusammengsetzten Schlüsseln arbeiten oder eine eindeutige Nummer selber vergeben oder als Auto-Increment. Es geht nicht anders. Man dichtet auch nichtrs hinzu. ID als unique identifier ist immer legitim. Eine UID ist es zwar auch, aber man bleibt bei der ID. Das wäre so OK.
An die Daten kommt man meist immer wieder einfach ran. Das Aufteilen in viele "komische" Tabellen sollte dich erstmal nicht stören. @LordGurke hat ja schon ein Bsp. dazu gegeben. WHERE-Part und geeignete Joins und der Groschen fällt recht schnell.
Komische Werte: Du bringst hier ein paar Dinge durcheinander. Bei DB geht es ja mehr um ref. Integrität. Man will auch Insert und Update Anomalien vermeiden. Da geht es mehr um Zuordnung der Tabellen zueinander.
Zeilenende oder Telenfonummern sind immer so eine Sache. Constraint wäre da auch schwierig. Man kann das eig. nur beim Befüllen abfangen - im Programm oder wenn mal INSERT Scripte schreibt auf den Weg.
Es gibt in Deutschland auch weniger Schreibweisen wie man denkt. ISO Vorlage mal anschauen und danach arbeiten. Zeilenende oder Tel.Nummern sind noch dankbar. Interessant wird es wenn sich die Codepage ändert. Oder auch wenn man cs hat und zwischen Groß- und Kleinschreibung unterscheidet.
Datenschrott einzutragen ist eine Sache, hat aber nichts mit der Normalisierung erstmal zu tun. Das kannst du hier esrtmal kurz ausblenden. Dennoch Daumen hoch, dass dir sowas auffällt. Genau so ein Mist kann später auch bei guten Aufbau zu Problemen führen. Nicht immer kann es durch Datentypen abfangen. TEXT ist immer noch ein schönes Format. Nimm Artikel-Nummern: die gibt es ja teils auch als Zahl-Buchstaben Kombination.
Collation und falsch gefüllte Felder machen Probleme. Sind erstmal bei INSERT und Update Anomalien zu vernachlössigen. Schlimmer ist es, wenn eine Tabelle von mehreren Tabellen nach dem Löschen die Kombi ID-Wert noch hat. Und man dann später mit der gleichen ID - gibt es ja nicht mehr - da wieder rangeht. Ist schon ein Wert drin.
Beliebt ist auch dass das Nichts oder Leere Masken-Felder die 0 haben. Hat nun jemand bei 0 eine Telefonnummer hinterlegt, so ist bei JEDEM Kunden dann auf einmal die gleiche Nummer drin.
Wie geht sowas? Indem man z.B. keinen Auto-Increment Wert hat und Anhand von Nummerkreisen selber für Eindeutigkeit sorgt. Ist in der laufenden Eingabe dann 0 mit Telefonnummer ZUNÄCHST gefüllt und es stürzt ab, hat man z.B. so ein Problem.
Der Task, der anhand des Nummerkreises eine ID holen sollte kam nicht zum Zuge. 4GL Sprache wie z.B. Magic uniPaaS und XPA können mit Dummy Werten arbeiten und am Ende wirde es weggeschrieben. KÖNNEN. mna kann aber auch direkt in die DB schreiben. Ist das Transaktions-Ende falsch hat man auf einmal bei ID 0 die Telefonnummer drin.
Hier geht es aber dann um das Befüllen bzw. die Logik dahinter. Name und Vorname sind nicht eindeutig. Eine ID sich auszudenken ist hier ein muss. Die Logik Fehler oben sind ein anderes Thema!
MwSt, Skonto und Anreden in Extra-Tabelle:
Du kannst auch hier noch einfacher Denken. Der User soll im Pulldown Menü eine Sache auswählen. Man kann alle Werte und Texte von Hand da reinschreiben. Oder man verlinkt eine Tabelle. Hier siehst du auch, dass es vollkommen ausreicht wenn diese Tabelle
ID, Anrede
1=Herr
2=Frau
3=Chuck NorrisSo hat es @Blackmann für die Nummern-Art genmacht.
Die User sind gierig!
Wenn es was nicht gibt, wird es halt erfunden! ERP Systeme sind Teuer. "Hier unten das Feld Ref. AA Nr. ist bei uns seit 30 J leer! Da kann ich doch was rein tun, damit wir endlich eine kaufmännische Freigabe haben".
"Dieser Artikel ist ###e. Ich schreib mal ein "-S" dahinter, damit es jeder weiß."
Dann kommt ein Update und alles ist weg. Oder man hat mit "*" selektiert und oh wunder auf einmal haben wir über all Duplikate in der Ausgabe.
"Mobil-Nummer 2 hat doch kein Mensch! Wir nehmen es einfach für diese neue, komsiche Steuer-Identifikationsnummer."
Wozu auf ein Update warten? Kostet doch nur Geld. wir füllen mal und in Crystal Reports isd das Feld dcoh auch da. Hey ich hab meinen eigenen Bericht erweitert!
Merkst du was? Willkommen in der Welte der Power- und Key-User im Unternehmen.
Zitat von @MysticFoxDE:
Moin @Tomtom33,
vielleicht tröstet dich das ja ein bisschen.
Soeben erreicht mich eine Mail von Intel, laut der angeblich die Garantie Erweiterung für zwei von uns erworbenen !! DUAL PROCESSOR !! NUC10I5FNH wohl ausgelaufen währe. 🙃
🤪
Sprich, selbst Intel hat seine Produkt-DB nicht wirklich zu 100% im Griff.
Gruss Alex
Moin @Tomtom33,
Da werde ich wohl mit dem Punktabzug leben müssen und danke euch für eure Antworten und Meinungen.
vielleicht tröstet dich das ja ein bisschen.
Soeben erreicht mich eine Mail von Intel, laut der angeblich die Garantie Erweiterung für zwei von uns erworbenen !! DUAL PROCESSOR !! NUC10I5FNH wohl ausgelaufen währe. 🙃
🤪
Sprich, selbst Intel hat seine Produkt-DB nicht wirklich zu 100% im Griff.
Gruss Alex
Lol, das ist wirklich erstaunlich ... 🤪
Laut Intel beträgt die Garantiezeit auch 3 Jahre und keine 2, naja und bei 4 Kernen ...
Intel nuc10i5FNH
Wie heißt es so schon?
Nobody is perfect
Ich danke dir für die Aufmunterung am Morgen. 😎
1
Moin @8585324113,
nö, ist eigentlich ganz easy.
😉
Gruss Alex
Tabellen nach Strings durchsuchen ist doch der letzte Mist.
nö, ist eigentlich ganz easy.
SELECT * FROM TABELLE WHERE FELD LIKE "%SUCHSTRING%" 😉
Gruss Alex
Zitat von @MysticFoxDE:
Moin @8585324113,
nö, ist eigentlich ganz easy.
Moin @8585324113,
Tabellen nach Strings durchsuchen ist doch der letzte Mist.
nö, ist eigentlich ganz easy.
Eig. schon. Interessan wird es, wenn man Daten aus den 90ern übernimmt und man OEM2ANSI noch mache muss. Oder es hätte vorher geschehen sollen.
@8585324113 Artikelnummer sind auch oftmals auch Strings....
Zitat von @Crusher79:
Eig. schon. Interessan wird es, wenn man Daten aus den 90ern übernimmt und man OEM2ANSI noch mache muss. Oder es hätte vorher geschehen sollen.
@8585324113 Artikelnummer sind auch oftmals auch Strings....
Zitat von @MysticFoxDE:
Moin @8585324113,
nö, ist eigentlich ganz easy.
Moin @8585324113,
Tabellen nach Strings durchsuchen ist doch der letzte Mist.
nö, ist eigentlich ganz easy.
Eig. schon. Interessan wird es, wenn man Daten aus den 90ern übernimmt und man OEM2ANSI noch mache muss. Oder es hätte vorher geschehen sollen.
@8585324113 Artikelnummer sind auch oftmals auch Strings....
Ja, aber wer im Jahr 2023 die Wahl hat und etwas Erfahrung, der wird sich jeden Datentyp dieser Art überlegen.
Wir haben eine Globale Einzelteilrückverfolgung. Darauf baut z. B. die Zusammenbauprüfung auf. Ein Auto besteht teilweise aus mehr als 1000 Einzelteilen mit einer Seriennummer.
Wenn du dann über Tabellen mit String suchst die Milliarden Zeilen und Werte haben, dann dauert das nicht nur, sondern der SQL Server will sehr sehr viele Ressourcen. Du kannst im alles anbieten, was der Markt hergibt, er inhaliert es vor deinen Augen.
Sind die Tabellen aus rein numerisches Geraffel optimiert, dann bekommst du viel zügiger deine Ergebnisse.
Auch belegen viele Sachen Platz im Storage und Bits und Bytes addieren sich. Wir haben 2017 auf datetime2 umgestellt und ich will es nicht übertreiben aber wir haben mittlerweile 50-100 Milliarden datetime2 Werte gespeichert, das geht dann in Größenordnungen.
Ein gutes DB-Design will mit Liebe und Zeit gemacht werden.
Zitat von @MysticFoxDE:
Moin @8585324113,
nö, ist eigentlich ganz easy.
😉
Gruss Alex
Moin @8585324113,
Tabellen nach Strings durchsuchen ist doch der letzte Mist.
nö, ist eigentlich ganz easy.
SELECT * FROM TABELLE WHERE FELD LIKE "%SUCHSTRING%" 😉
Gruss Alex
Sag doch einfach, dass Du nichts verstanden hast, dann versteht es auch jeder.
Und ja schön, du kannst ein Select posten.
Gibt es keinen Kunden den Du eine Antennenkabel ins Rack legen kannst?
1Zitat von @Crusher79:
Guten Morgen,
mir gefällt die Lösung von @Blackmann ebenfalls.
Ja die Sache mit der n-ten Normalform isst mir auch aufgefallen. Wenn es praxisnah sein soll, dann soll die Normalisierung ein Optimum heraus holen. Das wäre Stand 2023 immer noch die 3. NF oder sogar 3.5. Die 1. hast du ja locker erfüllt: Atomar und keine vielfachen Werte in einer Zelle. Du hast nur dann aufgehört.
1:1, 1:n oder m:n - hatte auch kurz gehardert ob man many-to-many bei den Typen noch unterbringen kann. @Blackmann hat die übliche Form mit beschrieben.
MwSt oder auch Skonto-Berechnung: ID, Prozent und Beschreibung.
ID: Es muss eindeutig sein! Namen sind es nicht. Auch bei den Positionen in Rechnunen kommt man nicht hin. Man kann entweder mit zusammengsetzten Schlüsseln arbeiten oder eine eindeutige Nummer selber vergeben oder als Auto-Increment. Es geht nicht anders. Man dichtet auch nichtrs hinzu. ID als unique identifier ist immer legitim. Eine UID ist es zwar auch, aber man bleibt bei der ID. Das wäre so OK.
An die Daten kommt man meist immer wieder einfach ran. Das Aufteilen in viele "komische" Tabellen sollte dich erstmal nicht stören. @LordGurke hat ja schon ein Bsp. dazu gegeben. WHERE-Part und geeignete Joins und der Groschen fällt recht schnell.
Komische Werte: Du bringst hier ein paar Dinge durcheinander. Bei DB geht es ja mehr um ref. Integrität. Man will auch Insert und Update Anomalien vermeiden. Da geht es mehr um Zuordnung der Tabellen zueinander.
Zeilenende oder Telenfonummern sind immer so eine Sache. Constraint wäre da auch schwierig. Man kann das eig. nur beim Befüllen abfangen - im Programm oder wenn mal INSERT Scripte schreibt auf den Weg.
Es gibt in Deutschland auch weniger Schreibweisen wie man denkt. ISO Vorlage mal anschauen und danach arbeiten. Zeilenende oder Tel.Nummern sind noch dankbar. Interessant wird es wenn sich die Codepage ändert. Oder auch wenn man cs hat und zwischen Groß- und Kleinschreibung unterscheidet.
Datenschrott einzutragen ist eine Sache, hat aber nichts mit der Normalisierung erstmal zu tun. Das kannst du hier esrtmal kurz ausblenden. Dennoch Daumen hoch, dass dir sowas auffällt. Genau so ein Mist kann später auch bei guten Aufbau zu Problemen führen. Nicht immer kann es durch Datentypen abfangen. TEXT ist immer noch ein schönes Format. Nimm Artikel-Nummern: die gibt es ja teils auch als Zahl-Buchstaben Kombination.
Collation und falsch gefüllte Felder machen Probleme. Sind erstmal bei INSERT und Update Anomalien zu vernachlössigen. Schlimmer ist es, wenn eine Tabelle von mehreren Tabellen nach dem Löschen die Kombi ID-Wert noch hat. Und man dann später mit der gleichen ID - gibt es ja nicht mehr - da wieder rangeht. Ist schon ein Wert drin.
Beliebt ist auch dass das Nichts oder Leere Masken-Felder die 0 haben. Hat nun jemand bei 0 eine Telefonnummer hinterlegt, so ist bei JEDEM Kunden dann auf einmal die gleiche Nummer drin.
Wie geht sowas? Indem man z.B. keinen Auto-Increment Wert hat und Anhand von Nummerkreisen selber für Eindeutigkeit sorgt. Ist in der laufenden Eingabe dann 0 mit Telefonnummer ZUNÄCHST gefüllt und es stürzt ab, hat man z.B. so ein Problem.
Der Task, der anhand des Nummerkreises eine ID holen sollte kam nicht zum Zuge. 4GL Sprache wie z.B. Magic uniPaaS und XPA können mit Dummy Werten arbeiten und am Ende wirde es weggeschrieben. KÖNNEN. mna kann aber auch direkt in die DB schreiben. Ist das Transaktions-Ende falsch hat man auf einmal bei ID 0 die Telefonnummer drin.
Hier geht es aber dann um das Befüllen bzw. die Logik dahinter. Name und Vorname sind nicht eindeutig. Eine ID sich auszudenken ist hier ein muss. Die Logik Fehler oben sind ein anderes Thema!
MwSt, Skonto und Anreden in Extra-Tabelle:
Du kannst auch hier noch einfacher Denken. Der User soll im Pulldown Menü eine Sache auswählen. Man kann alle Werte und Texte von Hand da reinschreiben. Oder man verlinkt eine Tabelle. Hier siehst du auch, dass es vollkommen ausreicht wenn diese Tabelle
So hat es @Blackmann für die Nummern-Art genmacht.
Die User sind gierig!
Wenn es was nicht gibt, wird es halt erfunden! ERP Systeme sind Teuer. "Hier unten das Feld Ref. AA Nr. ist bei uns seit 30 J leer! Da kann ich doch was rein tun, damit wir endlich eine kaufmännische Freigabe haben".
"Dieser Artikel ist ###e. Ich schreib mal ein "-S" dahinter, damit es jeder weiß."
Dann kommt ein Update und alles ist weg. Oder man hat mit "*" selektiert und oh wunder auf einmal haben wir über all Duplikate in der Ausgabe.
"Mobil-Nummer 2 hat doch kein Mensch! Wir nehmen es einfach für diese neue, komsiche Steuer-Identifikationsnummer."
Wozu auf ein Update warten? Kostet doch nur Geld. wir füllen mal und in Crystal Reports isd das Feld dcoh auch da. Hey ich hab meinen eigenen Bericht erweitert!
Merkst du was? Willkommen in der Welte der Power- und Key-User im Unternehmen.
Guten Morgen,
mir gefällt die Lösung von @Blackmann ebenfalls.
Ja die Sache mit der n-ten Normalform isst mir auch aufgefallen. Wenn es praxisnah sein soll, dann soll die Normalisierung ein Optimum heraus holen. Das wäre Stand 2023 immer noch die 3. NF oder sogar 3.5. Die 1. hast du ja locker erfüllt: Atomar und keine vielfachen Werte in einer Zelle. Du hast nur dann aufgehört.
1:1, 1:n oder m:n - hatte auch kurz gehardert ob man many-to-many bei den Typen noch unterbringen kann. @Blackmann hat die übliche Form mit beschrieben.
MwSt oder auch Skonto-Berechnung: ID, Prozent und Beschreibung.
ID: Es muss eindeutig sein! Namen sind es nicht. Auch bei den Positionen in Rechnunen kommt man nicht hin. Man kann entweder mit zusammengsetzten Schlüsseln arbeiten oder eine eindeutige Nummer selber vergeben oder als Auto-Increment. Es geht nicht anders. Man dichtet auch nichtrs hinzu. ID als unique identifier ist immer legitim. Eine UID ist es zwar auch, aber man bleibt bei der ID. Das wäre so OK.
An die Daten kommt man meist immer wieder einfach ran. Das Aufteilen in viele "komische" Tabellen sollte dich erstmal nicht stören. @LordGurke hat ja schon ein Bsp. dazu gegeben. WHERE-Part und geeignete Joins und der Groschen fällt recht schnell.
Komische Werte: Du bringst hier ein paar Dinge durcheinander. Bei DB geht es ja mehr um ref. Integrität. Man will auch Insert und Update Anomalien vermeiden. Da geht es mehr um Zuordnung der Tabellen zueinander.
Zeilenende oder Telenfonummern sind immer so eine Sache. Constraint wäre da auch schwierig. Man kann das eig. nur beim Befüllen abfangen - im Programm oder wenn mal INSERT Scripte schreibt auf den Weg.
Es gibt in Deutschland auch weniger Schreibweisen wie man denkt. ISO Vorlage mal anschauen und danach arbeiten. Zeilenende oder Tel.Nummern sind noch dankbar. Interessant wird es wenn sich die Codepage ändert. Oder auch wenn man cs hat und zwischen Groß- und Kleinschreibung unterscheidet.
Datenschrott einzutragen ist eine Sache, hat aber nichts mit der Normalisierung erstmal zu tun. Das kannst du hier esrtmal kurz ausblenden. Dennoch Daumen hoch, dass dir sowas auffällt. Genau so ein Mist kann später auch bei guten Aufbau zu Problemen führen. Nicht immer kann es durch Datentypen abfangen. TEXT ist immer noch ein schönes Format. Nimm Artikel-Nummern: die gibt es ja teils auch als Zahl-Buchstaben Kombination.
Collation und falsch gefüllte Felder machen Probleme. Sind erstmal bei INSERT und Update Anomalien zu vernachlössigen. Schlimmer ist es, wenn eine Tabelle von mehreren Tabellen nach dem Löschen die Kombi ID-Wert noch hat. Und man dann später mit der gleichen ID - gibt es ja nicht mehr - da wieder rangeht. Ist schon ein Wert drin.
Beliebt ist auch dass das Nichts oder Leere Masken-Felder die 0 haben. Hat nun jemand bei 0 eine Telefonnummer hinterlegt, so ist bei JEDEM Kunden dann auf einmal die gleiche Nummer drin.
Wie geht sowas? Indem man z.B. keinen Auto-Increment Wert hat und Anhand von Nummerkreisen selber für Eindeutigkeit sorgt. Ist in der laufenden Eingabe dann 0 mit Telefonnummer ZUNÄCHST gefüllt und es stürzt ab, hat man z.B. so ein Problem.
Der Task, der anhand des Nummerkreises eine ID holen sollte kam nicht zum Zuge. 4GL Sprache wie z.B. Magic uniPaaS und XPA können mit Dummy Werten arbeiten und am Ende wirde es weggeschrieben. KÖNNEN. mna kann aber auch direkt in die DB schreiben. Ist das Transaktions-Ende falsch hat man auf einmal bei ID 0 die Telefonnummer drin.
Hier geht es aber dann um das Befüllen bzw. die Logik dahinter. Name und Vorname sind nicht eindeutig. Eine ID sich auszudenken ist hier ein muss. Die Logik Fehler oben sind ein anderes Thema!
MwSt, Skonto und Anreden in Extra-Tabelle:
Du kannst auch hier noch einfacher Denken. Der User soll im Pulldown Menü eine Sache auswählen. Man kann alle Werte und Texte von Hand da reinschreiben. Oder man verlinkt eine Tabelle. Hier siehst du auch, dass es vollkommen ausreicht wenn diese Tabelle
ID, Anrede
1=Herr
2=Frau
3=Chuck NorrisSo hat es @Blackmann für die Nummern-Art genmacht.
Die User sind gierig!
Wenn es was nicht gibt, wird es halt erfunden! ERP Systeme sind Teuer. "Hier unten das Feld Ref. AA Nr. ist bei uns seit 30 J leer! Da kann ich doch was rein tun, damit wir endlich eine kaufmännische Freigabe haben".
"Dieser Artikel ist ###e. Ich schreib mal ein "-S" dahinter, damit es jeder weiß."
Dann kommt ein Update und alles ist weg. Oder man hat mit "*" selektiert und oh wunder auf einmal haben wir über all Duplikate in der Ausgabe.
"Mobil-Nummer 2 hat doch kein Mensch! Wir nehmen es einfach für diese neue, komsiche Steuer-Identifikationsnummer."
Wozu auf ein Update warten? Kostet doch nur Geld. wir füllen mal und in Crystal Reports isd das Feld dcoh auch da. Hey ich hab meinen eigenen Bericht erweitert!
Merkst du was? Willkommen in der Welte der Power- und Key-User im Unternehmen.
Ja, Danke für deine Ausführung, es ist halt immer vieles dabei zu bedenken, was nicht gleich offensichtlich erscheint und eine noch so gut konzeptionierte Datenbank kann auch durch Fehler in der Anwendung (oder direkte Datenmanipulation) schnell fehleranfällig werden, das sehe ich genauso.
Ich denke die Lösung von Blackmann ist da wirklich am sinnvollsten geeignet, um da zumindest eine unbegrenzte Erweiterbarkeit zu ermöglichen und derart Missbräuchliche Verwendung zu unterbinden.
Darf ich noch ein zwei Worte sagen?
Diese dritte Tabelle von Dir würde ich so nicht integrieren. Du hast hier noch 'CIP' eingeführt der in keinster Weise eindeutige Rückschlüsse auf den Inhalt des Datensatzes gibt. Die Kombination von 'PID' und'CTID' ist hier die primäre Zuordnung. Das ist ja Normalisierung.
Basis der Normalisierung ist das Verknüpfen der Tabellen. ICH erweitere sie gerne durch Primärschlüssel/Zahlen da ich hier den Überblick behalte, wo kommen eigentlich meine Daten her und sie sind immer 'unique' - eindeutig.
Viele schimpfen über Access, aber das 'Beziehungsfenster' dort ist wunderbar um den Überblick über die Daten zu erhalten.
Für mich ist die normalisierte Verknüpfung der Tabellen 'Primär'.
Wenn DAS dann sauber hinterlegt ist, kann ich durch SQL alle Ergebnisse filtern.
Mit Strings als Schlüssel zu arbeiten habe ich damals nicht gelernt, es ist auch ein Grauß ... alleine mögliche Schreibfehler ...
Sorry, das wollte ich noch loswerden.
Schönene Tag noch - BM
Zitat von @mysti
|CID|PID|CTID|CONTACT|
|-|-|-|-|
|1|1|1|040/110112|
|2|1|2|0170/123456789|
|3|1|3|mm@meier.de|
|4|1|3|max@meier.de|
|5|2|1|030/1234987|
|6|2|2|0171/987654321|
|7|2|2|0175/123456789|
|8|3|1|0234/1122222|
|9|3|3|schmitz@renate.de|
Gruss Alex
|CID|PID|CTID|CONTACT|
|-|-|-|-|
|1|1|1|040/110112|
|2|1|2|0170/123456789|
|3|1|3|mm@meier.de|
|4|1|3|max@meier.de|
|5|2|1|030/1234987|
|6|2|2|0171/987654321|
|7|2|2|0175/123456789|
|8|3|1|0234/1122222|
|9|3|3|schmitz@renate.de|
Gruss Alex
Diese dritte Tabelle von Dir würde ich so nicht integrieren. Du hast hier noch 'CIP' eingeführt der in keinster Weise eindeutige Rückschlüsse auf den Inhalt des Datensatzes gibt. Die Kombination von 'PID' und'CTID' ist hier die primäre Zuordnung. Das ist ja Normalisierung.
Basis der Normalisierung ist das Verknüpfen der Tabellen. ICH erweitere sie gerne durch Primärschlüssel/Zahlen da ich hier den Überblick behalte, wo kommen eigentlich meine Daten her und sie sind immer 'unique' - eindeutig.
Viele schimpfen über Access, aber das 'Beziehungsfenster' dort ist wunderbar um den Überblick über die Daten zu erhalten.
Für mich ist die normalisierte Verknüpfung der Tabellen 'Primär'.
Wenn DAS dann sauber hinterlegt ist, kann ich durch SQL alle Ergebnisse filtern.
Mit Strings als Schlüssel zu arbeiten habe ich damals nicht gelernt, es ist auch ein Grauß ... alleine mögliche Schreibfehler ...
Zitat von @Tomtom33:
Anhand der reinen Aufgabenstellung bin ich davon ausgegangen, dass die vorhandenen Daten normalisiert werden sollen, also quasi kein Typ, oder ähnliches, hinzugefügt werden soll (es sind ja zusätzliche Datenfelder dafür nötig), von daher bin ich auf meine Lösung gekommen.
Davon löse Dich bitte, Aufgabenstellung hin oder her ... wenn DU eine Lösung findest die BESSER/EINDEUTIGER ist als die in der Aufgabenstellung geforderte, dann verfolge sie und streite drum. Nur weil Dir einer eine Aufgabe stellt heißt es noch lange nicht, das die auch SINNVOLL/LOGISCH ist.Anhand der reinen Aufgabenstellung bin ich davon ausgegangen, dass die vorhandenen Daten normalisiert werden sollen, also quasi kein Typ, oder ähnliches, hinzugefügt werden soll (es sind ja zusätzliche Datenfelder dafür nötig), von daher bin ich auf meine Lösung gekommen.
Sorry, das wollte ich noch loswerden.
Schönene Tag noch - BM
Zitat von @Blackmann:
Sorry, das wollte ich noch loswerden.
Schönene Tag noch - BM
Zitat von @Tomtom33:
Anhand der reinen Aufgabenstellung bin ich davon ausgegangen, dass die vorhandenen Daten normalisiert werden sollen, also quasi kein Typ, oder ähnliches, hinzugefügt werden soll (es sind ja zusätzliche Datenfelder dafür nötig), von daher bin ich auf meine Lösung gekommen.
Davon löse Dich bitte, Aufgabenstellung hin oder her ... wenn DU eine Lösung findest die BESSER/EINDEUTIGER ist als die in der Aufgabenstellung geforderte, dann verfolge sie und streite drum. Nur weil Dir einer eine Aufgabe stellt heißt es noch lange nicht, das die auch SINNVOLL/LOGISCH ist.Anhand der reinen Aufgabenstellung bin ich davon ausgegangen, dass die vorhandenen Daten normalisiert werden sollen, also quasi kein Typ, oder ähnliches, hinzugefügt werden soll (es sind ja zusätzliche Datenfelder dafür nötig), von daher bin ich auf meine Lösung gekommen.
Sorry, das wollte ich noch loswerden.
Schönene Tag noch - BM
ja das werde ich beherzigen, vielen Dank und ich muss eingestehen, dass ich bei der 1:n Beziehung offensichtlich nicht weit genug nachgedacht habe.
Auch dir noch einen schönen Tag.
Moin @8585324113,
😉🙃
Nur keine Panik, die mit den integrierten Holzdioden, habe ich schon für dich zurücklegen lassen. 🤪
Gruss Alex
Sag doch einfach, dass Du nichts verstanden hast, dann versteht es auch jeder.
Gibt es keinen Kunden den Du eine Antennenkabel ins Rack legen kannst?
Nur keine Panik, die mit den integrierten Holzdioden, habe ich schon für dich zurücklegen lassen. 🤪
Gruss Alex
Moin @Blackmann,
es ging mir bei der CID auch nicht um die Normalisierung sondern viel mehr um den PK einer Tabelle, den ich absolut ungern über mehrere Felder ziehe. 😉
Gruss Alex
Diese dritte Tabelle von Dir würde ich so nicht integrieren. Du hast hier noch 'CIP' eingeführt der in keinster Weise eindeutige Rückschlüsse auf den Inhalt des Datensatzes gibt. Die Kombination von 'PID' und'CTID' ist hier die primäre Zuordnung. Das ist ja Normalisierung.
es ging mir bei der CID auch nicht um die Normalisierung sondern viel mehr um den PK einer Tabelle, den ich absolut ungern über mehrere Felder ziehe. 😉
Gruss Alex
Hallo,
bitte gewoehnt es euch an keine Deutschen Bezeichnungen für die Spalten zu verwenden, spaetestens bei einem UMLAUT kann das richtig witzig werden
gruese
bitte gewoehnt es euch an keine Deutschen Bezeichnungen für die Spalten zu verwenden, spaetestens bei einem UMLAUT kann das richtig witzig werden
gruese
1Zitat von @godlie:
Hallo,
bitte gewoehnt es euch an keine Deutschen Bezeichnungen für die Spalten zu verwenden, spaetestens bei einem UMLAUT kann das richtig witzig werden
gruese
Hallo,
bitte gewoehnt es euch an keine Deutschen Bezeichnungen für die Spalten zu verwenden, spaetestens bei einem UMLAUT kann das richtig witzig werden
gruese
ups, stimmt, gut dass Du es erwähnst, war meinem Dozenten offensichtlich auch nicht aufgefallen.
Vielen Dank für den Hinweis.
Zitat von @godlie:
Hallo,
bitte gewoehnt es euch an keine Deutschen Bezeichnungen für die Spalten zu verwenden, spaetestens bei einem UMLAUT kann das richtig witzig werden
gruese
Hallo,
bitte gewoehnt es euch an keine Deutschen Bezeichnungen für die Spalten zu verwenden, spaetestens bei einem UMLAUT kann das richtig witzig werden
gruese
Generell auch Bez. Deutsche alte Kasse vs. neue mit englischen Begriffen.
EAN vs. GTIN. Das macht auch im ersten Moment Aua.
Zitat von @Tomtom33:
ups, stimmt, gut dass Du es erwähnst, war meinem Dozenten offensichtlich auch nicht aufgefallen.
Vielen Dank für den Hinweis.
ups, stimmt, gut dass Du es erwähnst, war meinem Dozenten offensichtlich auch nicht aufgefallen.
Vielen Dank für den Hinweis.
Ist ja für die Normalisierung egal. Entitäten und Relationen kann man auch mit deutschen Begriffen abbilden. Wäre nun aber wirlich max. ein + Sternchen oder? Sonst kommen wir bei der Aufgabe ja nie zum Ende.
Atomar und keine doppelten Werte. Dann paar Relationen geabastelt und gut ist. Die paar Zeilen da sind ja kein komplettes ERP System. Irgendwann muss es ja mal gut sein.
Zitat von @Crusher79:
Ist ja für die Normalisierung egal. Entitäten und Relationen kann man auch mit deutschen Begriffen abbilden. Wäre nun aber wirlich max. ein + Sternchen oder? Sonst kommen wir bei der Aufgabe ja nie zum Ende.
Atomar und keine doppelten Werte. Dann paar Relationen geabastelt und gut ist. Die paar Zeilen da sind ja kein komplettes ERP System. Irgendwann muss es ja mal gut sein.
Zitat von @Tomtom33:
ups, stimmt, gut dass Du es erwähnst, war meinem Dozenten offensichtlich auch nicht aufgefallen.
Vielen Dank für den Hinweis.
ups, stimmt, gut dass Du es erwähnst, war meinem Dozenten offensichtlich auch nicht aufgefallen.
Vielen Dank für den Hinweis.
Ist ja für die Normalisierung egal. Entitäten und Relationen kann man auch mit deutschen Begriffen abbilden. Wäre nun aber wirlich max. ein + Sternchen oder? Sonst kommen wir bei der Aufgabe ja nie zum Ende.
Atomar und keine doppelten Werte. Dann paar Relationen geabastelt und gut ist. Die paar Zeilen da sind ja kein komplettes ERP System. Irgendwann muss es ja mal gut sein.
Kann man machen. Aber macht man sowas wirklich?
Man kann doch froh sein, dass man im Serverbereich fast alles ohne Komplikationen US-Englisch laufen lassen kann. Das war mal anders.
Server Os in deutsch, Exhange deutsch, SCCM deutsch... sieht man fast täglich.
Aber im SSMS und VS englisch programmieren mit deutschen Datenbankbezeichnungen finde ich mindestens anstrengend.
2Zitat von @Crusher79:
Ist ja für die Normalisierung egal. Entitäten und Relationen kann man auch mit deutschen Begriffen abbilden. Wäre nun aber wirlich max. ein + Sternchen oder? Sonst kommen wir bei der Aufgabe ja nie zum Ende.
Atomar und keine doppelten Werte. Dann paar Relationen geabastelt und gut ist. Die paar Zeilen da sind ja kein komplettes ERP System. Irgendwann muss es ja mal gut sein.
Zitat von @Tomtom33:
ups, stimmt, gut dass Du es erwähnst, war meinem Dozenten offensichtlich auch nicht aufgefallen.
Vielen Dank für den Hinweis.
ups, stimmt, gut dass Du es erwähnst, war meinem Dozenten offensichtlich auch nicht aufgefallen.
Vielen Dank für den Hinweis.
Ist ja für die Normalisierung egal. Entitäten und Relationen kann man auch mit deutschen Begriffen abbilden. Wäre nun aber wirlich max. ein + Sternchen oder? Sonst kommen wir bei der Aufgabe ja nie zum Ende.
Atomar und keine doppelten Werte. Dann paar Relationen geabastelt und gut ist. Die paar Zeilen da sind ja kein komplettes ERP System. Irgendwann muss es ja mal gut sein.
Ich denke das wichtigste ist sehr ausführlich von euch beschrieben worden.
Vielen Dank nochmal dafür an Alle.
LG
Zitat von @Tomtom33:
Ich denke das wichtigste ist sehr ausführlich von euch beschrieben worden.
Vielen Dank nochmal dafür an Alle.
LG
Ich denke das wichtigste ist sehr ausführlich von euch beschrieben worden.
Vielen Dank nochmal dafür an Alle.
LG
Kommt auch drauf an ob der Dozent ein Praktiker ist. Meiner hatte damals als Praktikant für eine Lokalzeitung die Verteilung der Zeitungen in Access abgebildet.
Oder Restaurant. Einer Kellner bedient mehrere Tische... Eins-Zu-Irgendwas.
Wenn du ganz verquer denkst und überlegst was in ein Pulldown Menü so gehört kommst du vlt. darüber auf andere Ideen. Anreden, Mehrwertsteuer, Skonto...
Mit so einen Gefühlt dafür solltest du dann an den vollen Punkten kratzen können. Das andere macht dann die Praxis und Erfahrung.
1Zitat von @Crusher79:
Kommt auch drauf an ob der Dozent ein Praktiker ist. Meiner hatte damals als Praktikant für eine Lokalzeitung die Verteilung der Zeitungen in Access abgebildet.
Zitat von @Tomtom33:
Ich denke das wichtigste ist sehr ausführlich von euch beschrieben worden.
Vielen Dank nochmal dafür an Alle.
LG
Ich denke das wichtigste ist sehr ausführlich von euch beschrieben worden.
Vielen Dank nochmal dafür an Alle.
LG
Kommt auch drauf an ob der Dozent ein Praktiker ist. Meiner hatte damals als Praktikant für eine Lokalzeitung die Verteilung der Zeitungen in Access abgebildet.
Basierend auf seiner Antwort würde ich da mal auf Theoretiker tippen.
Oder Restaurant. Einer Kellner bedient mehrere Tische... Eins-Zu-Irgendwas.
Wenn du ganz verquer denkst und überlegst was in ein Pulldown Menü so gehört kommst du vlt. darüber auf andere Ideen. Anreden, Mehrwertsteuer, Skonto...
Mit so einen Gefühlt dafür solltest du dann an den vollen Punkten kratzen können. Das andere macht dann die Praxis und Erfahrung.
Wenn du ganz verquer denkst und überlegst was in ein Pulldown Menü so gehört kommst du vlt. darüber auf andere Ideen. Anreden, Mehrwertsteuer, Skonto...
Mit so einen Gefühlt dafür solltest du dann an den vollen Punkten kratzen können. Das andere macht dann die Praxis und Erfahrung.
Ich vermute meine Ansicht dazu orientiert sich da zu sehr an der praktischen Umsetzung, anstatt an der reinen Theorie, was wohl dazu geführt hat, dass ich 1:n Relationen nicht ausreichend berücksichtigt hatte, da bei der Programmierung von bspw. Abfragen ja n fast immer endlich ist (wie aus einem Beispiel mit der Anrede).
Aber gut, das habe ich ja nun gelernt zu berücksichtigen und auch verstanden, warum es einen Unterschied machen kann, je nach Anwendungsfall 😃
Sry ich hab jetzt nicht alles gelesen und bin sicher, die Lösung ist dir jetzt bekannt. Da ich mich aber total gerne und oft mit Datenbanken und Normalisierung befasse wollte ich nochmal ein paar Anmerkungen machen.
Es gibt drei Wege das jetzt zu betrachten.
1.) Theorie. Da ist deine Lösung mal ziemlich falsch, da bist du mit 22/30 Punkten eher ziemlich gut weg gekommen. In der Theorie gehören E-Mail-Adressen in eine und Telefonnummern in eine andere Tabelle / Entität, jeweils in ein und die selbe Spalte - ein Datensatz pro Nummer / Adresse. Dabei ist die Nummer / Adresse selbst jeweils eigentlich nur ein Attribut und ein Typ, wie von dir eingefügt, wäre ein weitereres Attribut genau dieses Datensatzes. Die "Lücken" sprechen nicht gegen deine Lösung - Attribute dürfen NULL sein - aber die entsprechende Normalform gibt das so vor.
Übrigens ist der "Typ" von dir natürlich frei dazu erfunden, das gibt die Aufgabe nicht her. Ich verstehe deine Intention aber rein von den Daten kannst du diese Information so nicht ableiten. Was du aber sehr wohl kannst ist die Telefonnummer oder die E-Mail Adresse weiter zu zerlegen. Du kannst die Vorwahl der Rufnummer in eine eigene Spalte nehmen, theoretisch kannst du sie sogar in einer eigenen Tabelle abbilden und nur zuordnen. Das gleiche gilt für eine Domain und eine TLD. Ich glaube nicht, das der Prüfer darauf hinaus wollte, sonst hätte er Vorwahlen oder Domains mehrfach verwendet.
2.) Die "optimale" Lösung. Die optimale Lösung richtet sich natürlich am Bedarf aus. Bestes Beispiel sind PLZs in klassischen Adressen. Die kann man auch getrennt vom Ort in zwei Tabellen speichern, ein Ort kann verschiedene PLZ haben - bums zwei Tabellen. Macht natürlich keiner, viel zu viel Overhead für eine fünfstellige Zahl. Genauso verhält es sich mit fast allem anderen in der Welt. Normalisierung ist gut und wichtig aber nicht bis zur letzten Ebene.
Wenn die Aufgabenstellung einen Typ her gibt ist der sehr sinnvoll, z.B. um Mobilnetze und Festnetz zu unterscheiden (in der Realität gibt es natürlich auch "Festnetzanschlüsse" über Mobilfunk usw... Bei dem Typ kann man aber genauso argumentieren der gehört in eine eigene Tabelle und kann referenziert werden. Die optimale Lösung erfordert Entscheidungen die man in der Theorie nicht treffen muss sondern die Normalisierung nur stumpf aus den Daten ableitet.
Hier wären auch weitere Attribute für jede Entität interessant wie z.B. die Gültigkeit(sdauer) des Datensatzes, Zugriffsrechte, Datenschutz,...
3) Realität. Realität ist meist ganz anders weil viele Datenbanksysteme mit der Zeit wachsen aber natürlich die Datenstruktur nicht mit jedem Update komplett umschmeißen. Realtität ist daher meist weit weg vom Optimum und von der Theorie. Guck dir allein Outlook Kontakte an, eine Tabelle - totaler Schmarn. Aber viele Systeme zum Speichern von Kontaktdaten orientieren sich daran, dann gibt es genau die Attribute, mit denen du angefangen hast. Mobil 1, Mobil 2, etc.
Es gibt drei Wege das jetzt zu betrachten.
1.) Theorie. Da ist deine Lösung mal ziemlich falsch, da bist du mit 22/30 Punkten eher ziemlich gut weg gekommen. In der Theorie gehören E-Mail-Adressen in eine und Telefonnummern in eine andere Tabelle / Entität, jeweils in ein und die selbe Spalte - ein Datensatz pro Nummer / Adresse. Dabei ist die Nummer / Adresse selbst jeweils eigentlich nur ein Attribut und ein Typ, wie von dir eingefügt, wäre ein weitereres Attribut genau dieses Datensatzes. Die "Lücken" sprechen nicht gegen deine Lösung - Attribute dürfen NULL sein - aber die entsprechende Normalform gibt das so vor.
Übrigens ist der "Typ" von dir natürlich frei dazu erfunden, das gibt die Aufgabe nicht her. Ich verstehe deine Intention aber rein von den Daten kannst du diese Information so nicht ableiten. Was du aber sehr wohl kannst ist die Telefonnummer oder die E-Mail Adresse weiter zu zerlegen. Du kannst die Vorwahl der Rufnummer in eine eigene Spalte nehmen, theoretisch kannst du sie sogar in einer eigenen Tabelle abbilden und nur zuordnen. Das gleiche gilt für eine Domain und eine TLD. Ich glaube nicht, das der Prüfer darauf hinaus wollte, sonst hätte er Vorwahlen oder Domains mehrfach verwendet.
2.) Die "optimale" Lösung. Die optimale Lösung richtet sich natürlich am Bedarf aus. Bestes Beispiel sind PLZs in klassischen Adressen. Die kann man auch getrennt vom Ort in zwei Tabellen speichern, ein Ort kann verschiedene PLZ haben - bums zwei Tabellen. Macht natürlich keiner, viel zu viel Overhead für eine fünfstellige Zahl. Genauso verhält es sich mit fast allem anderen in der Welt. Normalisierung ist gut und wichtig aber nicht bis zur letzten Ebene.
Wenn die Aufgabenstellung einen Typ her gibt ist der sehr sinnvoll, z.B. um Mobilnetze und Festnetz zu unterscheiden (in der Realität gibt es natürlich auch "Festnetzanschlüsse" über Mobilfunk usw... Bei dem Typ kann man aber genauso argumentieren der gehört in eine eigene Tabelle und kann referenziert werden. Die optimale Lösung erfordert Entscheidungen die man in der Theorie nicht treffen muss sondern die Normalisierung nur stumpf aus den Daten ableitet.
Hier wären auch weitere Attribute für jede Entität interessant wie z.B. die Gültigkeit(sdauer) des Datensatzes, Zugriffsrechte, Datenschutz,...
3) Realität. Realität ist meist ganz anders weil viele Datenbanksysteme mit der Zeit wachsen aber natürlich die Datenstruktur nicht mit jedem Update komplett umschmeißen. Realtität ist daher meist weit weg vom Optimum und von der Theorie. Guck dir allein Outlook Kontakte an, eine Tabelle - totaler Schmarn. Aber viele Systeme zum Speichern von Kontaktdaten orientieren sich daran, dann gibt es genau die Attribute, mit denen du angefangen hast. Mobil 1, Mobil 2, etc.
Zitat von @ukulele-7:
Sry ich hab jetzt nicht alles gelesen und bin sicher, die Lösung ist dir jetzt bekannt. Da ich mich aber total gerne und oft mit Datenbanken und Normalisierung befasse wollte ich nochmal ein paar Anmerkungen machen.
Es gibt drei Wege das jetzt zu betrachten.
1.) Theorie. Da ist deine Lösung mal ziemlich falsch, da bist du mit 22/30 Punkten eher ziemlich gut weg gekommen. In der Theorie gehören E-Mail-Adressen in eine und Telefonnummern in eine andere Tabelle / Entität, jeweils in ein und die selbe Spalte - ein Datensatz pro Nummer / Adresse. Dabei ist die Nummer / Adresse selbst jeweils eigentlich nur ein Attribut und ein Typ, wie von dir eingefügt, wäre ein weitereres Attribut genau dieses Datensatzes. Die "Lücken" sprechen nicht gegen deine Lösung - Attribute dürfen NULL sein - aber die entsprechende Normalform gibt das so vor.
Übrigens ist der "Typ" von dir natürlich frei dazu erfunden, das gibt die Aufgabe nicht her. Ich verstehe deine Intention aber rein von den Daten kannst du diese Information so nicht ableiten. Was du aber sehr wohl kannst ist die Telefonnummer oder die E-Mail Adresse weiter zu zerlegen. Du kannst die Vorwahl der Rufnummer in eine eigene Spalte nehmen, theoretisch kannst du sie sogar in einer eigenen Tabelle abbilden und nur zuordnen. Das gleiche gilt für eine Domain und eine TLD. Ich glaube nicht, das der Prüfer darauf hinaus wollte, sonst hätte er Vorwahlen oder Domains mehrfach verwendet.
2.) Die "optimale" Lösung. Die optimale Lösung richtet sich natürlich am Bedarf aus. Bestes Beispiel sind PLZs in klassischen Adressen. Die kann man auch getrennt vom Ort in zwei Tabellen speichern, ein Ort kann verschiedene PLZ haben - bums zwei Tabellen. Macht natürlich keiner, viel zu viel Overhead für eine fünfstellige Zahl. Genauso verhält es sich mit fast allem anderen in der Welt. Normalisierung ist gut und wichtig aber nicht bis zur letzten Ebene.
Wenn die Aufgabenstellung einen Typ her gibt ist der sehr sinnvoll, z.B. um Mobilnetze und Festnetz zu unterscheiden (in der Realität gibt es natürlich auch "Festnetzanschlüsse" über Mobilfunk usw... Bei dem Typ kann man aber genauso argumentieren der gehört in eine eigene Tabelle und kann referenziert werden. Die optimale Lösung erfordert Entscheidungen die man in der Theorie nicht treffen muss sondern die Normalisierung nur stumpf aus den Daten ableitet.
Hier wären auch weitere Attribute für jede Entität interessant wie z.B. die Gültigkeit(sdauer) des Datensatzes, Zugriffsrechte, Datenschutz,...
3) Realität. Realität ist meist ganz anders weil viele Datenbanksysteme mit der Zeit wachsen aber natürlich die Datenstruktur nicht mit jedem Update komplett umschmeißen. Realtität ist daher meist weit weg vom Optimum und von der Theorie. Guck dir allein Outlook Kontakte an, eine Tabelle - totaler Schmarn. Aber viele Systeme zum Speichern von Kontaktdaten orientieren sich daran, dann gibt es genau die Attribute, mit denen du angefangen hast. Mobil 1, Mobil 2, etc.
Sry ich hab jetzt nicht alles gelesen und bin sicher, die Lösung ist dir jetzt bekannt. Da ich mich aber total gerne und oft mit Datenbanken und Normalisierung befasse wollte ich nochmal ein paar Anmerkungen machen.
Es gibt drei Wege das jetzt zu betrachten.
1.) Theorie. Da ist deine Lösung mal ziemlich falsch, da bist du mit 22/30 Punkten eher ziemlich gut weg gekommen. In der Theorie gehören E-Mail-Adressen in eine und Telefonnummern in eine andere Tabelle / Entität, jeweils in ein und die selbe Spalte - ein Datensatz pro Nummer / Adresse. Dabei ist die Nummer / Adresse selbst jeweils eigentlich nur ein Attribut und ein Typ, wie von dir eingefügt, wäre ein weitereres Attribut genau dieses Datensatzes. Die "Lücken" sprechen nicht gegen deine Lösung - Attribute dürfen NULL sein - aber die entsprechende Normalform gibt das so vor.
Übrigens ist der "Typ" von dir natürlich frei dazu erfunden, das gibt die Aufgabe nicht her. Ich verstehe deine Intention aber rein von den Daten kannst du diese Information so nicht ableiten. Was du aber sehr wohl kannst ist die Telefonnummer oder die E-Mail Adresse weiter zu zerlegen. Du kannst die Vorwahl der Rufnummer in eine eigene Spalte nehmen, theoretisch kannst du sie sogar in einer eigenen Tabelle abbilden und nur zuordnen. Das gleiche gilt für eine Domain und eine TLD. Ich glaube nicht, das der Prüfer darauf hinaus wollte, sonst hätte er Vorwahlen oder Domains mehrfach verwendet.
2.) Die "optimale" Lösung. Die optimale Lösung richtet sich natürlich am Bedarf aus. Bestes Beispiel sind PLZs in klassischen Adressen. Die kann man auch getrennt vom Ort in zwei Tabellen speichern, ein Ort kann verschiedene PLZ haben - bums zwei Tabellen. Macht natürlich keiner, viel zu viel Overhead für eine fünfstellige Zahl. Genauso verhält es sich mit fast allem anderen in der Welt. Normalisierung ist gut und wichtig aber nicht bis zur letzten Ebene.
Wenn die Aufgabenstellung einen Typ her gibt ist der sehr sinnvoll, z.B. um Mobilnetze und Festnetz zu unterscheiden (in der Realität gibt es natürlich auch "Festnetzanschlüsse" über Mobilfunk usw... Bei dem Typ kann man aber genauso argumentieren der gehört in eine eigene Tabelle und kann referenziert werden. Die optimale Lösung erfordert Entscheidungen die man in der Theorie nicht treffen muss sondern die Normalisierung nur stumpf aus den Daten ableitet.
Hier wären auch weitere Attribute für jede Entität interessant wie z.B. die Gültigkeit(sdauer) des Datensatzes, Zugriffsrechte, Datenschutz,...
3) Realität. Realität ist meist ganz anders weil viele Datenbanksysteme mit der Zeit wachsen aber natürlich die Datenstruktur nicht mit jedem Update komplett umschmeißen. Realtität ist daher meist weit weg vom Optimum und von der Theorie. Guck dir allein Outlook Kontakte an, eine Tabelle - totaler Schmarn. Aber viele Systeme zum Speichern von Kontaktdaten orientieren sich daran, dann gibt es genau die Attribute, mit denen du angefangen hast. Mobil 1, Mobil 2, etc.
Ja der Unterschied zwischen Theorie und Praxis, bei der Theorie kommt es halt definitiv nur auf die stumpfe Theorie an und dass, was sich direkt daraus ableiten lässt, egal ob es dann bei der Umsetzung zu Problemen führen kann, oder nicht, bzw. eine eindeutige Zuordnung in der Praxis nicht notwendig ist
Und ja, ich bin da wohl zu sehr von der Realität ausgegangen und habe die 1:n Beziehungen bei meiner Überlegung nicht berücksichtigt ...
Aber Danke nochmal für deine ausführliche Differenzierung.
Bei mir ist aber übrigens die Realität auch ein Eintrag pro Nummer / Adresse mit einigen Attributen mehr sowie FK auf Person und FK auf Unternehmen. Das hat sich für mich bewährt und das ließe sich auch nicht in der von dir angenommenen Form abbilden.
Zitat von @ukulele-7:
Bei mir ist aber übrigens die Realität auch ein Eintrag pro Nummer / Adresse mit einigen Attributen mehr sowie FK auf Person und FK auf Unternehmen. Das hat sich für mich bewährt und das ließe sich auch nicht in der von dir angenommenen Form abbilden.
Bei mir ist aber übrigens die Realität auch ein Eintrag pro Nummer / Adresse mit einigen Attributen mehr sowie FK auf Person und FK auf Unternehmen. Das hat sich für mich bewährt und das ließe sich auch nicht in der von dir angenommenen Form abbilden.
OH je, ich erinnere mich an meine alte Firma. Alles in den 90ern gewachsen.
Adress-Nummer und Adress-ID. Die Nummern kamen aus den Nummernkreis, gleichzeitig hatte jeder DS aber auch eine ID. Wir hatten Magic uniPaaS. Was aber hier nebensächlich ist.
Als ein arroganter C# Entwickler ins Team kam, wollte er es auch nach Wochen nicht verstehen. Nummer != ID.
Da kam Freude auf....
Ich habe grundsätzlich GUIDs als PK und bei einigen Datensätzen zusätzlich eine "sprechende" ID. Die ist aber tatsächlich nur für die Orientierung des Benutzers und hat keine technische Abhängigkeit.
Zitat von @ukulele-7:
Ich habe grundsätzlich GUIDs als PK und bei einigen Datensätzen zusätzlich eine "sprechende" ID. Die ist aber tatsächlich nur für die Orientierung des Benutzers und hat keine technische Abhängigkeit.
Ich habe grundsätzlich GUIDs als PK und bei einigen Datensätzen zusätzlich eine "sprechende" ID. Die ist aber tatsächlich nur für die Orientierung des Benutzers und hat keine technische Abhängigkeit.
Ja ist nicht verkerht. GUID ist aber auch tricky oder? Wir hatten MS SQL. Eine Kunde aber Oracle. Magic uniPaaS ist das ja egal. Nur die guid bei Oracle meine ich wird etwas anders erstellt. Das war auch etwas unschön.
Kenne ORA nicht so gut aber ich glaube die Unterschiede beizehen sich nur auf das Erstellen, nicht auf das Format als solches. Ist aber auch nicht sonderlich relevant, es ist einfach nur eine technisch eindeutige ID.
Wenn man mit sehr großen Datenmengen arbeitet würde man vermutlich eh BIGINT oder sowas nehmen. GUID nimmt halt viel Speicherplatz weg, ein INT fängt bei einer Stelle an und ist damit erstmal lange Zeit deutlich kleiner. Bei meinen 10k Unternehmen im CRM ist das aber total egal.
Wenn man mit sehr großen Datenmengen arbeitet würde man vermutlich eh BIGINT oder sowas nehmen. GUID nimmt halt viel Speicherplatz weg, ein INT fängt bei einer Stelle an und ist damit erstmal lange Zeit deutlich kleiner. Bei meinen 10k Unternehmen im CRM ist das aber total egal.
@ukulele-7 ja ist korrekt. Schlimm genug dass man ALTER Table für MS SQL und Oracle separat handle muss. Für die guid gilt oder galt das Gleiche. Die Art war etwas anders ....
Datum ist auch noch lustig. Magic kennt separate Date und Time Felder Man kann aber Haken setzen, dass Datum so aufgeteilt wird.
Oh man mir fallen so viele Dinge gerade ein. Richtig Bock wieder was zu bauen
Datum ist auch noch lustig. Magic kennt separate Date und Time Felder Man kann aber Haken setzen, dass Datum so aufgeteilt wird.
Oh man mir fallen so viele Dinge gerade ein. Richtig Bock wieder was zu bauen
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Zitat von @NamenlosChris:
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Zitat von @Crusher79:
@ukulele-7 ja ist korrekt. Schlimm genug dass man ALTER Table für MS SQL und Oracle separat handle muss. Für die guid gilt oder galt das Gleiche. Die Art war etwas anders ....
Datum ist auch noch lustig. Magic kennt separate Date und Time Felder Man kann aber Haken setzen, dass Datum so aufgeteilt wird.
Oh man mir fallen so viele Dinge gerade ein. Richtig Bock wieder was zu bauen
@ukulele-7 ja ist korrekt. Schlimm genug dass man ALTER Table für MS SQL und Oracle separat handle muss. Für die guid gilt oder galt das Gleiche. Die Art war etwas anders ....
Datum ist auch noch lustig. Magic kennt separate Date und Time Felder Man kann aber Haken setzen, dass Datum so aufgeteilt wird.
Oh man mir fallen so viele Dinge gerade ein. Richtig Bock wieder was zu bauen
Na dann immer ran, das kann nie schaden 🤩
Btw. gibt es eigentlich eine API-Lösung für eine Datenbank die Postleitzahlen, Orte und Straßenzüge umfasst, also eine als Dienstleistung?
Wenn nicht, könnte es vlt. einigen Firmen helfen (gegen Bezahlung versteht sich), wenn es darum geht Straßen Postleitzahlen zuzuordnen usw., was ansonsten doch sehr komplex in einer Eigenlösung sein dürfte, man betrachte nur mal die Postleitzahlen in Berlin und Hamburg etc. wo einzelne Straßen teilweise mehrere Postleitzahlen besitzen, oder 1 Postleitzahl mehrere Orte umfasst.
Das wäre sicherlich ein anspruchsvolleres Projekt und vielleicht sogar profitabel ...
Zitat von @Tomtom33:
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Zitat von @NamenlosChris:
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Ich habe die DSGVO gelesen, von Löschfristen steht da nichts. Die werden jedenfalls nicht vorgegeben wie tatsächlich Aufbewahrungsfristen im Rahmen der GoBD. Auch in deinem Link sind keine expliziten Löschfristen oder auch nur das Wort enthalten. Richtig ist natürlich das Daten nicht ohne Grund aufbewahrt werden dürfen und im Rahmen der technisch organisatiorischen Maßnahmen auch fristen festgelegt werden können / sollten.
Abgesehen davon sind B2C Kontakte nicht zwingend personenbeziehbare Daten, zumindest theoretisch. Wenn da jetzt nur Vorname Nachname in der E-Mail Adresse enthalten ist dann muss das aus meiner Sicht nicht gelöscht werden. Wenn du aber zur guten Kontaktpflege noch seine Vorliebe für Golf in deinem CRM stehen hast, dann ist das zu löschen.
Zitat von @Tomtom33:
Btw. gibt es eigentlich eine API-Lösung für eine Datenbank die Postleitzahlen, Orte und Straßenzüge umfasst, also eine als Dienstleistung?
Ja die gibt es, von Google Maps z.B. Aber natürlich ist das Datenschutztechnisch schon wieder nicht so geil, vor allem wenn du ganze Adressen abfragst und an Google übermittelst.Btw. gibt es eigentlich eine API-Lösung für eine Datenbank die Postleitzahlen, Orte und Straßenzüge umfasst, also eine als Dienstleistung?
Für PLZ habe ich eine Tabelle von OpenGeoDB mit PLZ zu Ort eingepflegt. Ich hab auch von irgendwo (Bundesnetzagentur?) eine Liste mit Ortsvorwahlen und Ortsnetznamen eingebaut. Der Umfang ist in beiden Fällen nicht so groß. Früher gabs das auch von so klassischen Navigationssoftware-Anbietern, die noch mit Daten CDs daher kam. Da konnte man dann ganze Adressen vervollständigen.
Ja früher kam man da einfacher ran.
Wollte mal Entfernung zum Strassenverkehrsamt jeweils berechnen. Hab da auch etwas gebraucht, bis ich eine brauchbare Excel Tabelle gefunden hab, die auch Kennzeichen mit einschließt.
https://public.opendatasoft.com/explore/dataset/georef-germany-postleitz ...
Da ist auch sogar der Kreiscode - brauchte ich - mit drin. Schaut schon ganz gut aus.
https://www.datenbörse.net/item/Postleitzahlenverzeichnis_2021_Exce ...
150 Tsd. Stück. Dürfte auch bauchbar sein. Excel oder CSV.....
Naja es git viel Licht und Schatten.
Wollte mal Entfernung zum Strassenverkehrsamt jeweils berechnen. Hab da auch etwas gebraucht, bis ich eine brauchbare Excel Tabelle gefunden hab, die auch Kennzeichen mit einschließt.
https://public.opendatasoft.com/explore/dataset/georef-germany-postleitz ...
Da ist auch sogar der Kreiscode - brauchte ich - mit drin. Schaut schon ganz gut aus.
https://www.datenbörse.net/item/Postleitzahlenverzeichnis_2021_Exce ...
150 Tsd. Stück. Dürfte auch bauchbar sein. Excel oder CSV.....
Naja es git viel Licht und Schatten.
Steht auch nirgends weder damals im BDSG, welches heute noch und eigentlich nur noch von Seiten der Behörden genutzt wird, hier gilt nicht die DSGVO, noch in der DSGVO. Lediglich steht drin, dass nach einer (zweckgebundenen) Verarbeitung die Daten gelöscht werden müssen. Das ist aber sehr dehnbar. Letztlich muss man aber auf Forderung des Kunden die Daten löschen, wenn er dies wünscht. Aber auch hier gilt eine wesentliche Einschränkung, die bereits erwähnt wurde -> GoBD
Zitat von @Tomtom33:
Wenn nicht, könnte es vlt. einigen Firmen helfen (gegen Bezahlung versteht sich), wenn es darum geht Straßen Postleitzahlen zuzuordnen usw., was ansonsten doch sehr komplex in einer Eigenlösung sein dürfte, man betrachte nur mal die Postleitzahlen in Berlin und Hamburg etc. wo einzelne Straßen teilweise mehrere Postleitzahlen besitzen, oder 1 Postleitzahl mehrere Orte umfasst.
Das wäre sicherlich ein anspruchsvolleres Projekt und vielleicht sogar profitabel ...
Wenn nicht, könnte es vlt. einigen Firmen helfen (gegen Bezahlung versteht sich), wenn es darum geht Straßen Postleitzahlen zuzuordnen usw., was ansonsten doch sehr komplex in einer Eigenlösung sein dürfte, man betrachte nur mal die Postleitzahlen in Berlin und Hamburg etc. wo einzelne Straßen teilweise mehrere Postleitzahlen besitzen, oder 1 Postleitzahl mehrere Orte umfasst.
Das wäre sicherlich ein anspruchsvolleres Projekt und vielleicht sogar profitabel ...
https://where2b-conference.com/fileadmin/where2b/resources/documets/arch ...
Schau dir mal diesen Vortrag an. Dann wird die Sache klarer. Auch wo noch die Lücken auch in 2023 liegen werden.
Ich denke die meisten werden für den Vertrieb etc. solche Daten kaufen. Auch wenn es möglich ist, es so zu beschaffen.
Zitat von @ukulele-7:
Ich habe die DSGVO gelesen, von Löschfristen steht da nichts. Die werden jedenfalls nicht vorgegeben wie tatsächlich Aufbewahrungsfristen im Rahmen der GoBD. Auch in deinem Link sind keine expliziten Löschfristen oder auch nur das Wort enthalten. Richtig ist natürlich das Daten nicht ohne Grund aufbewahrt werden dürfen und im Rahmen der technisch organisatiorischen Maßnahmen auch fristen festgelegt werden können / sollten.
Abgesehen davon sind B2C Kontakte nicht zwingend personenbeziehbare Daten, zumindest theoretisch. Wenn da jetzt nur Vorname Nachname in der E-Mail Adresse enthalten ist dann muss das aus meiner Sicht nicht gelöscht werden. Wenn du aber zur guten Kontaktpflege noch seine Vorliebe für Golf in deinem CRM stehen hast, dann ist das zu löschen.
Zitat von @Tomtom33:
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Zitat von @NamenlosChris:
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Ich habe die DSGVO gelesen, von Löschfristen steht da nichts. Die werden jedenfalls nicht vorgegeben wie tatsächlich Aufbewahrungsfristen im Rahmen der GoBD. Auch in deinem Link sind keine expliziten Löschfristen oder auch nur das Wort enthalten. Richtig ist natürlich das Daten nicht ohne Grund aufbewahrt werden dürfen und im Rahmen der technisch organisatiorischen Maßnahmen auch fristen festgelegt werden können / sollten.
Abgesehen davon sind B2C Kontakte nicht zwingend personenbeziehbare Daten, zumindest theoretisch. Wenn da jetzt nur Vorname Nachname in der E-Mail Adresse enthalten ist dann muss das aus meiner Sicht nicht gelöscht werden. Wenn du aber zur guten Kontaktpflege noch seine Vorliebe für Golf in deinem CRM stehen hast, dann ist das zu löschen.
Nur mal ein Zitat aus meinem Link:
"Nach Art. 5 Abs. 1 lit. b DS-GVO dürfen personenbezogene Daten nur unter den aufgeführten Bedingungen verarbeitet und gespeichert werden. Entfallen diese Gründe, ist die Zweckbindung nicht mehr gegeben und Unternehmen müssen die Daten entsprechend löschen. Diesem Löschgebot stehen gesetzliche Aufbewahrungsfristen für personenbezogene Daten und anderen Daten oder Dokumenten gegenüber. Die Aufbewahrungsfristen stellen nun die neue Zweckbindung dar. Diese Daten, die den Aufbewahrungsfristen unterliegen, werden nach den Fristen gelöscht bzw. vernichtet."
Aber natürlich gilt das nur für B2C, also für Endverbraucher.
Und ja, es ist sehr verwirrend und wenn ein Interessent seine explizite Einwilligung zur Speicherung gegeben hat, die er jederzeit widerrufen kann, dann gelten solange auch kein Fristen, wie man darüber einen Nachweis erbringen kann. In jedem Fall gilt aber das "Gebot der Datensparsamkeit" und das BDSG spielt da auch eine Rolle.
Wie genau das Datenkraken wie Google umgehen, darüber kann man nur spekulieren, aber auch die mussten schon horrende Strafen zahlen und Dinge ändern.
Aber vielleicht hilft ja dieser Link bei die Risiken für Firmen betrachtet:
Datenschutz Kundendaten
Aber alles in Allem ist das Ganze so verwirrend und widersprüchlich, dass es mich nicht verwundert, wenn viele Firmen damit Problem haben was die Löschung anbelangt, oder auch die Einhaltung.
Interessant dürfte es werden, wenn man bei Google eine entsprechende Anfrage stellen würde, was die so alles über einen gespeichert haben 8die sind ja verpflichtet dazu), aber da wird vermutlich vieles über die anonymisierte Schiene laufen, mit der die Speicherung verschleiert wird (also nicht direkt zuzuordnen, aber halt über Umwege (UUID bspw. die im Browser als Cookie , oder in einer Datei gespeichert werden könnten) dennoch möglich ist. Auch die Windows-Seriennummer könnte dafür verwendet werden etc.. zumindest ließen sich darüber Daten erfassen und speichern, die Augenscheinlich keinen Bezug zu personenbezogenen Daten hätten, aber dennoch indirekt zuzuordnen wären.
Also potentielle Lücken sehe ich da sehr viele und ein wirklicher Nachweis dürfte bei Google und Co äußerst schwierig werden.
Zitat von @Tomtom33:
Nur mal ein Zitat aus meinem Link:
"Nach Art. 5 Abs. 1 lit. b DS-GVO dürfen personenbezogene Daten nur unter den aufgeführten Bedingungen verarbeitet und gespeichert werden. Entfallen diese Gründe, ist die Zweckbindung nicht mehr gegeben und Unternehmen müssen die Daten entsprechend löschen. Diesem Löschgebot stehen gesetzliche Aufbewahrungsfristen für personenbezogene Daten und anderen Daten oder Dokumenten gegenüber. Die Aufbewahrungsfristen stellen nun die neue Zweckbindung dar. Diese Daten, die den Aufbewahrungsfristen unterliegen, werden nach den Fristen gelöscht bzw. vernichtet."
Aber natürlich gilt das nur für B2C, also für Endverbraucher.
Und ja, es ist sehr verwirrend und wenn ein Interessent seine explizite Einwilligung zur Speicherung gegeben hat, die er jederzeit widerrufen kann, dann gelten solange auch kein Fristen, wie man darüber einen Nachweis erbringen kann. In jedem Fall gilt aber das "Gebot der Datensparsamkeit" und das BDSG spielt da auch eine Rolle.
Wie genau das Datenkraken wie Google umgehen, darüber kann man nur spekulieren, aber auch die mussten schon horrende Strafen zahlen und Dinge ändern.
Aber vielleicht hilft ja dieser Link bei die Risiken für Firmen betrachtet:
Datenschutz Kundendaten
Aber alles in Allem ist das Ganze so verwirrend und widersprüchlich, dass es mich nicht verwundert, wenn viele Firmen damit Problem haben was die Löschung anbelangt, oder auch die Einhaltung.
Interessant dürfte es werden, wenn man bei Google eine entsprechende Anfrage stellen würde, was die so alles über einen gespeichert haben 8die sind ja verpflichtet dazu), aber da wird vermutlich vieles über die anonymisierte Schiene laufen, mit der die Speicherung verschleiert wird (also nicht direkt zuzuordnen, aber halt über Umwege (UUID bspw. die im Browser als Cookie , oder in einer Datei gespeichert werden könnten) dennoch möglich ist. Auch die Windows-Seriennummer könnte dafür verwendet werden etc.. zumindest ließen sich darüber Daten erfassen und speichern, die Augenscheinlich keinen Bezug zu personenbezogenen Daten hätten, aber dennoch indirekt zuzuordnen wären.
Also potentielle Lücken sehe ich da sehr viele und ein wirklicher Nachweis dürfte bei Google und Co äußerst schwierig werden.
Zitat von @ukulele-7:
Ich habe die DSGVO gelesen, von Löschfristen steht da nichts. Die werden jedenfalls nicht vorgegeben wie tatsächlich Aufbewahrungsfristen im Rahmen der GoBD. Auch in deinem Link sind keine expliziten Löschfristen oder auch nur das Wort enthalten. Richtig ist natürlich das Daten nicht ohne Grund aufbewahrt werden dürfen und im Rahmen der technisch organisatiorischen Maßnahmen auch fristen festgelegt werden können / sollten.
Abgesehen davon sind B2C Kontakte nicht zwingend personenbeziehbare Daten, zumindest theoretisch. Wenn da jetzt nur Vorname Nachname in der E-Mail Adresse enthalten ist dann muss das aus meiner Sicht nicht gelöscht werden. Wenn du aber zur guten Kontaktpflege noch seine Vorliebe für Golf in deinem CRM stehen hast, dann ist das zu löschen.
Zitat von @Tomtom33:
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Zitat von @NamenlosChris:
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Ich habe die DSGVO gelesen, von Löschfristen steht da nichts. Die werden jedenfalls nicht vorgegeben wie tatsächlich Aufbewahrungsfristen im Rahmen der GoBD. Auch in deinem Link sind keine expliziten Löschfristen oder auch nur das Wort enthalten. Richtig ist natürlich das Daten nicht ohne Grund aufbewahrt werden dürfen und im Rahmen der technisch organisatiorischen Maßnahmen auch fristen festgelegt werden können / sollten.
Abgesehen davon sind B2C Kontakte nicht zwingend personenbeziehbare Daten, zumindest theoretisch. Wenn da jetzt nur Vorname Nachname in der E-Mail Adresse enthalten ist dann muss das aus meiner Sicht nicht gelöscht werden. Wenn du aber zur guten Kontaktpflege noch seine Vorliebe für Golf in deinem CRM stehen hast, dann ist das zu löschen.
Nur mal ein Zitat aus meinem Link:
"Nach Art. 5 Abs. 1 lit. b DS-GVO dürfen personenbezogene Daten nur unter den aufgeführten Bedingungen verarbeitet und gespeichert werden. Entfallen diese Gründe, ist die Zweckbindung nicht mehr gegeben und Unternehmen müssen die Daten entsprechend löschen. Diesem Löschgebot stehen gesetzliche Aufbewahrungsfristen für personenbezogene Daten und anderen Daten oder Dokumenten gegenüber. Die Aufbewahrungsfristen stellen nun die neue Zweckbindung dar. Diese Daten, die den Aufbewahrungsfristen unterliegen, werden nach den Fristen gelöscht bzw. vernichtet."
Aber natürlich gilt das nur für B2C, also für Endverbraucher.
Und ja, es ist sehr verwirrend und wenn ein Interessent seine explizite Einwilligung zur Speicherung gegeben hat, die er jederzeit widerrufen kann, dann gelten solange auch kein Fristen, wie man darüber einen Nachweis erbringen kann. In jedem Fall gilt aber das "Gebot der Datensparsamkeit" und das BDSG spielt da auch eine Rolle.
Wie genau das Datenkraken wie Google umgehen, darüber kann man nur spekulieren, aber auch die mussten schon horrende Strafen zahlen und Dinge ändern.
Aber vielleicht hilft ja dieser Link bei die Risiken für Firmen betrachtet:
Datenschutz Kundendaten
Aber alles in Allem ist das Ganze so verwirrend und widersprüchlich, dass es mich nicht verwundert, wenn viele Firmen damit Problem haben was die Löschung anbelangt, oder auch die Einhaltung.
Interessant dürfte es werden, wenn man bei Google eine entsprechende Anfrage stellen würde, was die so alles über einen gespeichert haben 8die sind ja verpflichtet dazu), aber da wird vermutlich vieles über die anonymisierte Schiene laufen, mit der die Speicherung verschleiert wird (also nicht direkt zuzuordnen, aber halt über Umwege (UUID bspw. die im Browser als Cookie , oder in einer Datei gespeichert werden könnten) dennoch möglich ist. Auch die Windows-Seriennummer könnte dafür verwendet werden etc.. zumindest ließen sich darüber Daten erfassen und speichern, die Augenscheinlich keinen Bezug zu personenbezogenen Daten hätten, aber dennoch indirekt zuzuordnen wären.
Also potentielle Lücken sehe ich da sehr viele und ein wirklicher Nachweis dürfte bei Google und Co äußerst schwierig werden.
Nachdem Google seinen Sitz in den USA hat greift hier schon einmal nicht das BDSG. Das Thema US-Unternehmen ist hier nun aber auch zu umfangreich. Ich werfe nun nur ein paar Stichworte in den Raum: Safe Harbor (Unter anderem gescheitert nach Edward Snowden), US-EU Privacy Shield (gescheitert), Cloud Act (fraglich). Letztlich machen alle US-Unternehmen auch heute Selbstverpflichtungen, damit sie Daten aus der EU verarbeiten dürfen. Es ist aber nach wie vor sehr strittig -> Patriot Act.
Und das BDSG greift hier längst nicht mehr. Es wurde nicht umsonst die EU-DSGVO ins Leben gerufen, um vor allem verstärkt das Thema Internet mit aufzunehmen, da dies auch in Deutschland eher weniger geregelt war. ABER, wenn man es großzügig betrachtet, dann war vieles auch vorher schon sehr stark geregelt zB: über das BDSG ergänzend mit dem TMG. Nur sind halt heute die Strafen deutlich höher. Und wie schon oben geschrieben: Das BDSG findet nur noch im öffentlichen Sektor Anwendung. Genauso wie das KDG nur in kirchlichen Einrichtungen zu tragen kommt. Die DSGVO wiederum für Unternehmen.
Zitat von @Crusher79:
https://where2b-conference.com/fileadmin/where2b/resources/documets/arch ...
Schau dir mal diesen Vortrag an. Dann wird die Sache klarer. Auch wo noch die Lücken auch in 2023 liegen werden.
Ich denke die meisten werden für den Vertrieb etc. solche Daten kaufen. Auch wenn es möglich ist, es so zu beschaffen.
Zitat von @Tomtom33:
Wenn nicht, könnte es vlt. einigen Firmen helfen (gegen Bezahlung versteht sich), wenn es darum geht Straßen Postleitzahlen zuzuordnen usw., was ansonsten doch sehr komplex in einer Eigenlösung sein dürfte, man betrachte nur mal die Postleitzahlen in Berlin und Hamburg etc. wo einzelne Straßen teilweise mehrere Postleitzahlen besitzen, oder 1 Postleitzahl mehrere Orte umfasst.
Das wäre sicherlich ein anspruchsvolleres Projekt und vielleicht sogar profitabel ...
Wenn nicht, könnte es vlt. einigen Firmen helfen (gegen Bezahlung versteht sich), wenn es darum geht Straßen Postleitzahlen zuzuordnen usw., was ansonsten doch sehr komplex in einer Eigenlösung sein dürfte, man betrachte nur mal die Postleitzahlen in Berlin und Hamburg etc. wo einzelne Straßen teilweise mehrere Postleitzahlen besitzen, oder 1 Postleitzahl mehrere Orte umfasst.
Das wäre sicherlich ein anspruchsvolleres Projekt und vielleicht sogar profitabel ...
https://where2b-conference.com/fileadmin/where2b/resources/documets/arch ...
Schau dir mal diesen Vortrag an. Dann wird die Sache klarer. Auch wo noch die Lücken auch in 2023 liegen werden.
Ich denke die meisten werden für den Vertrieb etc. solche Daten kaufen. Auch wenn es möglich ist, es so zu beschaffen.
Interessant, auch wenn die Datei Stand 11/2016 hat und klar, das ist wirklich sehr aufwändig, zumal sich das ja auch noch auf Einwohnerzahlen etc. erstreckt und offensichtlich über Anfragen bei den Meldeämtern.
Ich weiß von einer Datenbank die über die Post läuft (zumindest war das etwa 2015, als ich bei einem Verlag gearbeitet hatte und wo die Zusteller getrackt wurden) und viele der Daten wohl umfasst, nur zu Unsummen (wenn ich mich recht entsinne war das ein hoher 6stelliger Betrag), dafür aber mit Geodaten, die über GPS ausgewertet wurden. Im System konnte man dann Live die Zustellungen verfolgen und an welcher Adresse sich Betreffende befand. nur halt Postleitzahlen gab es meines Wissens nach nicht.
Mittlerweile ist das zwar Standard in einigen Bereichen, aber sowas fand ich damals schon krass.
Eine offensichtlich sehr umfangreiche Seite mit entsprechenden Daten ist onlinestreet.de, hier ein Beispiel:
20359 Hamburg auf Onlinestreet.de
Einziges Manko auf den ersten Blick, man kann da nicht eindeutig ermitteln welcher Hausnummernbereich zu welcher Postleitzahl gehört, wenn diese mehrere Postleitzahlen umfasst, bzw. überhaupt den Hausnummernbereich.
Aber offensichtlich gibt es da Möglichkeiten an derartige Daten zu kommen, ohne dafür erst einen hohen geldbetrag investieren zu müssen. mit entsprechenden, automatisierten Skripten wäre das auch automatisiert denkbar, die Daten zu sammeln und auszuwerten, nur eben nicht geeignet um da indirekte Abfragen zu gestalten.
Vielleicht nicht ganz legal, aber auch nicht ganz illegal so an Daten zu kommen.
Zitat von @NamenlosChris:
Nachdem Google seinen Sitz in den USA hat greift hier schon einmal nicht das BDSG. Das Thema US-Unternehmen ist hier nun aber auch zu umfangreich. Ich werfe nun nur ein paar Stichworte in den Raum: Safe Harbor (Unter anderem gescheitert nach Edward Snowden), US-EU Privacy Shield (gescheitert), Cloud Act (fraglich). Letztlich machen alle US-Unternehmen auch heute Selbstverpflichtungen, damit sie Daten aus der EU verarbeiten dürfen. Es ist aber nach wie vor sehr strittig -> Patriot Act.
Und das BDSG greift hier längst nicht mehr. Es wurde nicht umsonst die EU-DSGVO ins Leben gerufen, um vor allem verstärkt das Thema Internet mit aufzunehmen, da dies auch in Deutschland eher weniger geregelt war. ABER, wenn man es großzügig betrachtet, dann war vieles auch vorher schon sehr stark geregelt zB: über das BDSG ergänzend mit dem TMG. Nur sind halt heute die Strafen deutlich höher. Und wie schon oben geschrieben: Das BDSG findet nur noch im öffentlichen Sektor Anwendung. Genauso wie das KDG nur in kirchlichen Einrichtungen zu tragen kommt. Die DSGVO wiederum für Unternehmen.
Zitat von @Tomtom33:
Nur mal ein Zitat aus meinem Link:
"Nach Art. 5 Abs. 1 lit. b DS-GVO dürfen personenbezogene Daten nur unter den aufgeführten Bedingungen verarbeitet und gespeichert werden. Entfallen diese Gründe, ist die Zweckbindung nicht mehr gegeben und Unternehmen müssen die Daten entsprechend löschen. Diesem Löschgebot stehen gesetzliche Aufbewahrungsfristen für personenbezogene Daten und anderen Daten oder Dokumenten gegenüber. Die Aufbewahrungsfristen stellen nun die neue Zweckbindung dar. Diese Daten, die den Aufbewahrungsfristen unterliegen, werden nach den Fristen gelöscht bzw. vernichtet."
Aber natürlich gilt das nur für B2C, also für Endverbraucher.
Und ja, es ist sehr verwirrend und wenn ein Interessent seine explizite Einwilligung zur Speicherung gegeben hat, die er jederzeit widerrufen kann, dann gelten solange auch kein Fristen, wie man darüber einen Nachweis erbringen kann. In jedem Fall gilt aber das "Gebot der Datensparsamkeit" und das BDSG spielt da auch eine Rolle.
Wie genau das Datenkraken wie Google umgehen, darüber kann man nur spekulieren, aber auch die mussten schon horrende Strafen zahlen und Dinge ändern.
Aber vielleicht hilft ja dieser Link bei die Risiken für Firmen betrachtet:
Datenschutz Kundendaten
Aber alles in Allem ist das Ganze so verwirrend und widersprüchlich, dass es mich nicht verwundert, wenn viele Firmen damit Problem haben was die Löschung anbelangt, oder auch die Einhaltung.
Interessant dürfte es werden, wenn man bei Google eine entsprechende Anfrage stellen würde, was die so alles über einen gespeichert haben 8die sind ja verpflichtet dazu), aber da wird vermutlich vieles über die anonymisierte Schiene laufen, mit der die Speicherung verschleiert wird (also nicht direkt zuzuordnen, aber halt über Umwege (UUID bspw. die im Browser als Cookie , oder in einer Datei gespeichert werden könnten) dennoch möglich ist. Auch die Windows-Seriennummer könnte dafür verwendet werden etc.. zumindest ließen sich darüber Daten erfassen und speichern, die Augenscheinlich keinen Bezug zu personenbezogenen Daten hätten, aber dennoch indirekt zuzuordnen wären.
Also potentielle Lücken sehe ich da sehr viele und ein wirklicher Nachweis dürfte bei Google und Co äußerst schwierig werden.
Zitat von @ukulele-7:
Ich habe die DSGVO gelesen, von Löschfristen steht da nichts. Die werden jedenfalls nicht vorgegeben wie tatsächlich Aufbewahrungsfristen im Rahmen der GoBD. Auch in deinem Link sind keine expliziten Löschfristen oder auch nur das Wort enthalten. Richtig ist natürlich das Daten nicht ohne Grund aufbewahrt werden dürfen und im Rahmen der technisch organisatiorischen Maßnahmen auch fristen festgelegt werden können / sollten.
Abgesehen davon sind B2C Kontakte nicht zwingend personenbeziehbare Daten, zumindest theoretisch. Wenn da jetzt nur Vorname Nachname in der E-Mail Adresse enthalten ist dann muss das aus meiner Sicht nicht gelöscht werden. Wenn du aber zur guten Kontaktpflege noch seine Vorliebe für Golf in deinem CRM stehen hast, dann ist das zu löschen.
Zitat von @Tomtom33:
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Zitat von @NamenlosChris:
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Ich habe die DSGVO gelesen, von Löschfristen steht da nichts. Die werden jedenfalls nicht vorgegeben wie tatsächlich Aufbewahrungsfristen im Rahmen der GoBD. Auch in deinem Link sind keine expliziten Löschfristen oder auch nur das Wort enthalten. Richtig ist natürlich das Daten nicht ohne Grund aufbewahrt werden dürfen und im Rahmen der technisch organisatiorischen Maßnahmen auch fristen festgelegt werden können / sollten.
Abgesehen davon sind B2C Kontakte nicht zwingend personenbeziehbare Daten, zumindest theoretisch. Wenn da jetzt nur Vorname Nachname in der E-Mail Adresse enthalten ist dann muss das aus meiner Sicht nicht gelöscht werden. Wenn du aber zur guten Kontaktpflege noch seine Vorliebe für Golf in deinem CRM stehen hast, dann ist das zu löschen.
Nur mal ein Zitat aus meinem Link:
"Nach Art. 5 Abs. 1 lit. b DS-GVO dürfen personenbezogene Daten nur unter den aufgeführten Bedingungen verarbeitet und gespeichert werden. Entfallen diese Gründe, ist die Zweckbindung nicht mehr gegeben und Unternehmen müssen die Daten entsprechend löschen. Diesem Löschgebot stehen gesetzliche Aufbewahrungsfristen für personenbezogene Daten und anderen Daten oder Dokumenten gegenüber. Die Aufbewahrungsfristen stellen nun die neue Zweckbindung dar. Diese Daten, die den Aufbewahrungsfristen unterliegen, werden nach den Fristen gelöscht bzw. vernichtet."
Aber natürlich gilt das nur für B2C, also für Endverbraucher.
Und ja, es ist sehr verwirrend und wenn ein Interessent seine explizite Einwilligung zur Speicherung gegeben hat, die er jederzeit widerrufen kann, dann gelten solange auch kein Fristen, wie man darüber einen Nachweis erbringen kann. In jedem Fall gilt aber das "Gebot der Datensparsamkeit" und das BDSG spielt da auch eine Rolle.
Wie genau das Datenkraken wie Google umgehen, darüber kann man nur spekulieren, aber auch die mussten schon horrende Strafen zahlen und Dinge ändern.
Aber vielleicht hilft ja dieser Link bei die Risiken für Firmen betrachtet:
Datenschutz Kundendaten
Aber alles in Allem ist das Ganze so verwirrend und widersprüchlich, dass es mich nicht verwundert, wenn viele Firmen damit Problem haben was die Löschung anbelangt, oder auch die Einhaltung.
Interessant dürfte es werden, wenn man bei Google eine entsprechende Anfrage stellen würde, was die so alles über einen gespeichert haben 8die sind ja verpflichtet dazu), aber da wird vermutlich vieles über die anonymisierte Schiene laufen, mit der die Speicherung verschleiert wird (also nicht direkt zuzuordnen, aber halt über Umwege (UUID bspw. die im Browser als Cookie , oder in einer Datei gespeichert werden könnten) dennoch möglich ist. Auch die Windows-Seriennummer könnte dafür verwendet werden etc.. zumindest ließen sich darüber Daten erfassen und speichern, die Augenscheinlich keinen Bezug zu personenbezogenen Daten hätten, aber dennoch indirekt zuzuordnen wären.
Also potentielle Lücken sehe ich da sehr viele und ein wirklicher Nachweis dürfte bei Google und Co äußerst schwierig werden.
Nachdem Google seinen Sitz in den USA hat greift hier schon einmal nicht das BDSG. Das Thema US-Unternehmen ist hier nun aber auch zu umfangreich. Ich werfe nun nur ein paar Stichworte in den Raum: Safe Harbor (Unter anderem gescheitert nach Edward Snowden), US-EU Privacy Shield (gescheitert), Cloud Act (fraglich). Letztlich machen alle US-Unternehmen auch heute Selbstverpflichtungen, damit sie Daten aus der EU verarbeiten dürfen. Es ist aber nach wie vor sehr strittig -> Patriot Act.
Und das BDSG greift hier längst nicht mehr. Es wurde nicht umsonst die EU-DSGVO ins Leben gerufen, um vor allem verstärkt das Thema Internet mit aufzunehmen, da dies auch in Deutschland eher weniger geregelt war. ABER, wenn man es großzügig betrachtet, dann war vieles auch vorher schon sehr stark geregelt zB: über das BDSG ergänzend mit dem TMG. Nur sind halt heute die Strafen deutlich höher. Und wie schon oben geschrieben: Das BDSG findet nur noch im öffentlichen Sektor Anwendung. Genauso wie das KDG nur in kirchlichen Einrichtungen zu tragen kommt. Die DSGVO wiederum für Unternehmen.
Sicherlich ist das transatlantische Hick-Hack für rein in Amerika agierende Unternehmen nicht das gleiche, nur Google hat seine Europazentrale in Dublin, sowie diverse Niederlassungen bspw. in Hamburg und Berlin, auch wenn der Hauptsitz natürlich in Mountain View liegt. Soweit ich weiß, werden in Dublin auch die Haupt-Rechenzentren für Europa betrieben, die Kundendaten für Europa liegen also auch in Europa, ähnliches gilt für bspw. ebay.
Man darf dabei auch nicht außer Acht lassen, dass ja Verträge mit europäischen Endverbrauchern zustande kommen.
Das kann man auch sehr gut bei Google selbst nachlesen, indem man das Recht auf Vergessenwerden sich anschaut:
Das Recht auf Vergessenwerden
dieses gilt natürlich nur für natürliche Personen, ist aber eines der Bestandteile der DSGVO, die ja in Amerika nicht gilt. Auch gibt es diesbezüglich ein Urteil, wonach Google das nur in den Staaten anwenden muss, die zur EU gehören. Wie Du daran ersehen kannst, ist Google in Europa sehr wohl an die DSGVO gebunden, welches im übrigen ein EU-Recht ist, das von allen Mitgliedsstaaten umgesetzt worden ist.
Bei der BDSG verhält es sich etwas anders, wie man unschwer beim BMI nachlesen kann:
Zitat:
"Das Bundesdatenschutzgesetz (BDSG) ergänzt seit dem 25. Mai 2018 die unmittelbar geltende Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung) um die Bereiche, in denen die EU-Verordnung den Mitgliedstaaten Gestaltungsspielräume belässt. Daneben werden mit dem BDSG wesentliche Teile der Richtlinie (EU) 2016/680 (Datenschutz-Richtlinie Polizei und Justiz) umgesetzt."
Also hat in diesem Bereich jedes EU-Land einen gewissen Ermessensspielraum, was jedoch nicht heißt, dass das für Google dadurch nicht gilt, sondern einfach nur, dass es von EU-Land zu EU-Land unterschiedlich ausfallen kann.
Ob für Google dadurch dann die entsprechende Umsetzung von Irland gilt, oder die hiesige BDSG kann da wohl nur ein Jurist sagen, der sich damit auskennt.
Zitat von @Tomtom33:
Sicherlich ist das transatlantische Hick-Hack für rein in Amerika agierende Unternehmen nicht das gleiche, nur Google hat seine Europazentrale in Dublin, sowie diverse Niederlassungen bspw. in Hamburg und Berlin, auch wenn der Hauptsitz natürlich in Mountain View liegt. Soweit ich weiß, werden in Dublin auch die Haupt-Rechenzentren für Europa betrieben, die Kundendaten für Europa liegen also auch in Europa, ähnliches gilt für bspw. ebay.
Man darf dabei auch nicht außer Acht lassen, dass ja Verträge mit europäischen Endverbrauchern zustande kommen.
Das kann man auch sehr gut bei Google selbst nachlesen, indem man das Recht auf Vergessenwerden sich anschaut:
Das Recht auf Vergessenwerden
dieses gilt natürlich nur für natürliche Personen, ist aber eines der Bestandteile der DSGVO, die ja in Amerika nicht gilt. Auch gibt es diesbezüglich ein Urteil, wonach Google das nur in den Staaten anwenden muss, die zur EU gehören. Wie Du daran ersehen kannst, ist Google in Europa sehr wohl an die DSGVO gebunden, welches im übrigen ein EU-Recht ist, das von allen Mitgliedsstaaten umgesetzt worden ist.
Bei der BDSG verhält es sich etwas anders, wie man unschwer beim BMI nachlesen kann:
Zitat:
"Das Bundesdatenschutzgesetz (BDSG) ergänzt seit dem 25. Mai 2018 die unmittelbar geltende Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung) um die Bereiche, in denen die EU-Verordnung den Mitgliedstaaten Gestaltungsspielräume belässt. Daneben werden mit dem BDSG wesentliche Teile der Richtlinie (EU) 2016/680 (Datenschutz-Richtlinie Polizei und Justiz) umgesetzt."
Also hat in diesem Bereich jedes EU-Land einen gewissen Ermessensspielraum, was jedoch nicht heißt, dass das für Google dadurch nicht gilt, sondern einfach nur, dass es von EU-Land zu EU-Land unterschiedlich ausfallen kann.
Ob für Google dadurch dann die entsprechende Umsetzung von Irland gilt, oder die hiesige BDSG kann da wohl nur ein Jurist sagen, der sich damit auskennt.
Zitat von @NamenlosChris:
Nachdem Google seinen Sitz in den USA hat greift hier schon einmal nicht das BDSG. Das Thema US-Unternehmen ist hier nun aber auch zu umfangreich. Ich werfe nun nur ein paar Stichworte in den Raum: Safe Harbor (Unter anderem gescheitert nach Edward Snowden), US-EU Privacy Shield (gescheitert), Cloud Act (fraglich). Letztlich machen alle US-Unternehmen auch heute Selbstverpflichtungen, damit sie Daten aus der EU verarbeiten dürfen. Es ist aber nach wie vor sehr strittig -> Patriot Act.
Und das BDSG greift hier längst nicht mehr. Es wurde nicht umsonst die EU-DSGVO ins Leben gerufen, um vor allem verstärkt das Thema Internet mit aufzunehmen, da dies auch in Deutschland eher weniger geregelt war. ABER, wenn man es großzügig betrachtet, dann war vieles auch vorher schon sehr stark geregelt zB: über das BDSG ergänzend mit dem TMG. Nur sind halt heute die Strafen deutlich höher. Und wie schon oben geschrieben: Das BDSG findet nur noch im öffentlichen Sektor Anwendung. Genauso wie das KDG nur in kirchlichen Einrichtungen zu tragen kommt. Die DSGVO wiederum für Unternehmen.
Zitat von @Tomtom33:
Nur mal ein Zitat aus meinem Link:
"Nach Art. 5 Abs. 1 lit. b DS-GVO dürfen personenbezogene Daten nur unter den aufgeführten Bedingungen verarbeitet und gespeichert werden. Entfallen diese Gründe, ist die Zweckbindung nicht mehr gegeben und Unternehmen müssen die Daten entsprechend löschen. Diesem Löschgebot stehen gesetzliche Aufbewahrungsfristen für personenbezogene Daten und anderen Daten oder Dokumenten gegenüber. Die Aufbewahrungsfristen stellen nun die neue Zweckbindung dar. Diese Daten, die den Aufbewahrungsfristen unterliegen, werden nach den Fristen gelöscht bzw. vernichtet."
Aber natürlich gilt das nur für B2C, also für Endverbraucher.
Und ja, es ist sehr verwirrend und wenn ein Interessent seine explizite Einwilligung zur Speicherung gegeben hat, die er jederzeit widerrufen kann, dann gelten solange auch kein Fristen, wie man darüber einen Nachweis erbringen kann. In jedem Fall gilt aber das "Gebot der Datensparsamkeit" und das BDSG spielt da auch eine Rolle.
Wie genau das Datenkraken wie Google umgehen, darüber kann man nur spekulieren, aber auch die mussten schon horrende Strafen zahlen und Dinge ändern.
Aber vielleicht hilft ja dieser Link bei die Risiken für Firmen betrachtet:
Datenschutz Kundendaten
Aber alles in Allem ist das Ganze so verwirrend und widersprüchlich, dass es mich nicht verwundert, wenn viele Firmen damit Problem haben was die Löschung anbelangt, oder auch die Einhaltung.
Interessant dürfte es werden, wenn man bei Google eine entsprechende Anfrage stellen würde, was die so alles über einen gespeichert haben 8die sind ja verpflichtet dazu), aber da wird vermutlich vieles über die anonymisierte Schiene laufen, mit der die Speicherung verschleiert wird (also nicht direkt zuzuordnen, aber halt über Umwege (UUID bspw. die im Browser als Cookie , oder in einer Datei gespeichert werden könnten) dennoch möglich ist. Auch die Windows-Seriennummer könnte dafür verwendet werden etc.. zumindest ließen sich darüber Daten erfassen und speichern, die Augenscheinlich keinen Bezug zu personenbezogenen Daten hätten, aber dennoch indirekt zuzuordnen wären.
Also potentielle Lücken sehe ich da sehr viele und ein wirklicher Nachweis dürfte bei Google und Co äußerst schwierig werden.
Zitat von @ukulele-7:
Ich habe die DSGVO gelesen, von Löschfristen steht da nichts. Die werden jedenfalls nicht vorgegeben wie tatsächlich Aufbewahrungsfristen im Rahmen der GoBD. Auch in deinem Link sind keine expliziten Löschfristen oder auch nur das Wort enthalten. Richtig ist natürlich das Daten nicht ohne Grund aufbewahrt werden dürfen und im Rahmen der technisch organisatiorischen Maßnahmen auch fristen festgelegt werden können / sollten.
Abgesehen davon sind B2C Kontakte nicht zwingend personenbeziehbare Daten, zumindest theoretisch. Wenn da jetzt nur Vorname Nachname in der E-Mail Adresse enthalten ist dann muss das aus meiner Sicht nicht gelöscht werden. Wenn du aber zur guten Kontaktpflege noch seine Vorliebe für Golf in deinem CRM stehen hast, dann ist das zu löschen.
Zitat von @Tomtom33:
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Zitat von @NamenlosChris:
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Wenn dir der Kunde (B2C) x verschiedene Rufnummern gibt unter der er erreichbar ist und du ihn anrufen darfst, dann verstößt dies nicht gegen die DSGVO und hat auch zu keinem früheren Zeitpunkt gegen das BDSG verstoßen. Noch nie. Die Erhebung muss zweckgebunden sein.
Nicht ganz richtig, denn die DSGVO hat für alle Daten festgelegte Löschfristen, eine dauerhafte Speicherung ohne Begründung außerhalb der Fristen (also bspw. wenn ein Kunde nur eine Anfrage gestellt hatte und sich lange nicht mehr gemeldet hat) verstößt es dann sehr wohl dagegen.
Siehe hier:
Löschfristen und Aufbewahrung
Ich habe die DSGVO gelesen, von Löschfristen steht da nichts. Die werden jedenfalls nicht vorgegeben wie tatsächlich Aufbewahrungsfristen im Rahmen der GoBD. Auch in deinem Link sind keine expliziten Löschfristen oder auch nur das Wort enthalten. Richtig ist natürlich das Daten nicht ohne Grund aufbewahrt werden dürfen und im Rahmen der technisch organisatiorischen Maßnahmen auch fristen festgelegt werden können / sollten.
Abgesehen davon sind B2C Kontakte nicht zwingend personenbeziehbare Daten, zumindest theoretisch. Wenn da jetzt nur Vorname Nachname in der E-Mail Adresse enthalten ist dann muss das aus meiner Sicht nicht gelöscht werden. Wenn du aber zur guten Kontaktpflege noch seine Vorliebe für Golf in deinem CRM stehen hast, dann ist das zu löschen.
Nur mal ein Zitat aus meinem Link:
"Nach Art. 5 Abs. 1 lit. b DS-GVO dürfen personenbezogene Daten nur unter den aufgeführten Bedingungen verarbeitet und gespeichert werden. Entfallen diese Gründe, ist die Zweckbindung nicht mehr gegeben und Unternehmen müssen die Daten entsprechend löschen. Diesem Löschgebot stehen gesetzliche Aufbewahrungsfristen für personenbezogene Daten und anderen Daten oder Dokumenten gegenüber. Die Aufbewahrungsfristen stellen nun die neue Zweckbindung dar. Diese Daten, die den Aufbewahrungsfristen unterliegen, werden nach den Fristen gelöscht bzw. vernichtet."
Aber natürlich gilt das nur für B2C, also für Endverbraucher.
Und ja, es ist sehr verwirrend und wenn ein Interessent seine explizite Einwilligung zur Speicherung gegeben hat, die er jederzeit widerrufen kann, dann gelten solange auch kein Fristen, wie man darüber einen Nachweis erbringen kann. In jedem Fall gilt aber das "Gebot der Datensparsamkeit" und das BDSG spielt da auch eine Rolle.
Wie genau das Datenkraken wie Google umgehen, darüber kann man nur spekulieren, aber auch die mussten schon horrende Strafen zahlen und Dinge ändern.
Aber vielleicht hilft ja dieser Link bei die Risiken für Firmen betrachtet:
Datenschutz Kundendaten
Aber alles in Allem ist das Ganze so verwirrend und widersprüchlich, dass es mich nicht verwundert, wenn viele Firmen damit Problem haben was die Löschung anbelangt, oder auch die Einhaltung.
Interessant dürfte es werden, wenn man bei Google eine entsprechende Anfrage stellen würde, was die so alles über einen gespeichert haben 8die sind ja verpflichtet dazu), aber da wird vermutlich vieles über die anonymisierte Schiene laufen, mit der die Speicherung verschleiert wird (also nicht direkt zuzuordnen, aber halt über Umwege (UUID bspw. die im Browser als Cookie , oder in einer Datei gespeichert werden könnten) dennoch möglich ist. Auch die Windows-Seriennummer könnte dafür verwendet werden etc.. zumindest ließen sich darüber Daten erfassen und speichern, die Augenscheinlich keinen Bezug zu personenbezogenen Daten hätten, aber dennoch indirekt zuzuordnen wären.
Also potentielle Lücken sehe ich da sehr viele und ein wirklicher Nachweis dürfte bei Google und Co äußerst schwierig werden.
Nachdem Google seinen Sitz in den USA hat greift hier schon einmal nicht das BDSG. Das Thema US-Unternehmen ist hier nun aber auch zu umfangreich. Ich werfe nun nur ein paar Stichworte in den Raum: Safe Harbor (Unter anderem gescheitert nach Edward Snowden), US-EU Privacy Shield (gescheitert), Cloud Act (fraglich). Letztlich machen alle US-Unternehmen auch heute Selbstverpflichtungen, damit sie Daten aus der EU verarbeiten dürfen. Es ist aber nach wie vor sehr strittig -> Patriot Act.
Und das BDSG greift hier längst nicht mehr. Es wurde nicht umsonst die EU-DSGVO ins Leben gerufen, um vor allem verstärkt das Thema Internet mit aufzunehmen, da dies auch in Deutschland eher weniger geregelt war. ABER, wenn man es großzügig betrachtet, dann war vieles auch vorher schon sehr stark geregelt zB: über das BDSG ergänzend mit dem TMG. Nur sind halt heute die Strafen deutlich höher. Und wie schon oben geschrieben: Das BDSG findet nur noch im öffentlichen Sektor Anwendung. Genauso wie das KDG nur in kirchlichen Einrichtungen zu tragen kommt. Die DSGVO wiederum für Unternehmen.
Sicherlich ist das transatlantische Hick-Hack für rein in Amerika agierende Unternehmen nicht das gleiche, nur Google hat seine Europazentrale in Dublin, sowie diverse Niederlassungen bspw. in Hamburg und Berlin, auch wenn der Hauptsitz natürlich in Mountain View liegt. Soweit ich weiß, werden in Dublin auch die Haupt-Rechenzentren für Europa betrieben, die Kundendaten für Europa liegen also auch in Europa, ähnliches gilt für bspw. ebay.
Man darf dabei auch nicht außer Acht lassen, dass ja Verträge mit europäischen Endverbrauchern zustande kommen.
Das kann man auch sehr gut bei Google selbst nachlesen, indem man das Recht auf Vergessenwerden sich anschaut:
Das Recht auf Vergessenwerden
dieses gilt natürlich nur für natürliche Personen, ist aber eines der Bestandteile der DSGVO, die ja in Amerika nicht gilt. Auch gibt es diesbezüglich ein Urteil, wonach Google das nur in den Staaten anwenden muss, die zur EU gehören. Wie Du daran ersehen kannst, ist Google in Europa sehr wohl an die DSGVO gebunden, welches im übrigen ein EU-Recht ist, das von allen Mitgliedsstaaten umgesetzt worden ist.
Bei der BDSG verhält es sich etwas anders, wie man unschwer beim BMI nachlesen kann:
Zitat:
"Das Bundesdatenschutzgesetz (BDSG) ergänzt seit dem 25. Mai 2018 die unmittelbar geltende Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung) um die Bereiche, in denen die EU-Verordnung den Mitgliedstaaten Gestaltungsspielräume belässt. Daneben werden mit dem BDSG wesentliche Teile der Richtlinie (EU) 2016/680 (Datenschutz-Richtlinie Polizei und Justiz) umgesetzt."
Also hat in diesem Bereich jedes EU-Land einen gewissen Ermessensspielraum, was jedoch nicht heißt, dass das für Google dadurch nicht gilt, sondern einfach nur, dass es von EU-Land zu EU-Land unterschiedlich ausfallen kann.
Ob für Google dadurch dann die entsprechende Umsetzung von Irland gilt, oder die hiesige BDSG kann da wohl nur ein Jurist sagen, der sich damit auskennt.
Sorry für die direkten Worte, aber das ist einfach zu simpel gedacht. Nicht umsonst "streiten" die Landesdatenschützer seit Jahren. Auch wenn Google oder Microsoft ihre Daten in Dublin hat, bleibt folgendes: 1. Sie sind ein US Unternehmen. Bedeutet, auch dann hat die USA ein Anrecht darauf, wenn sie der Meinung sind die Daten einsehen zu wollen (Patriot Act), diese anzusehen. 2. Ist es nicht vermeidbar, dass auch Telemetriedaten in die USA gehen. Auch anhand dieser Daten kann man heutzutage viele Rückschlüsse ziehen. Großes Problem auch bei Videokonferenzen mit Teams oder Zoom. Auch wenn Microsoft selbst sagt, dass sie in Frankfurt oder Berlin ihre deutschen Server haben, dennoch ist es ein US Unternehmen. Niederlassungen hin oder her. Das ganze Thema ist nicht umsonst seit Jahren nicht final geklärt.
Zitat von @ukulele-7:
Für PLZ habe ich eine Tabelle von OpenGeoDB mit PLZ zu Ort eingepflegt. Ich hab auch von irgendwo (Bundesnetzagentur?) eine Liste mit Ortsvorwahlen und Ortsnetznamen eingebaut. Der Umfang ist in beiden Fällen nicht so groß. Früher gabs das auch von so klassischen Navigationssoftware-Anbietern, die noch mit Daten CDs daher kam. Da konnte man dann ganze Adressen vervollständigen.
Zitat von @Tomtom33:
Btw. gibt es eigentlich eine API-Lösung für eine Datenbank die Postleitzahlen, Orte und Straßenzüge umfasst, also eine als Dienstleistung?
Ja die gibt es, von Google Maps z.B. Aber natürlich ist das Datenschutztechnisch schon wieder nicht so geil, vor allem wenn du ganze Adressen abfragst und an Google übermittelst.Btw. gibt es eigentlich eine API-Lösung für eine Datenbank die Postleitzahlen, Orte und Straßenzüge umfasst, also eine als Dienstleistung?
Für PLZ habe ich eine Tabelle von OpenGeoDB mit PLZ zu Ort eingepflegt. Ich hab auch von irgendwo (Bundesnetzagentur?) eine Liste mit Ortsvorwahlen und Ortsnetznamen eingebaut. Der Umfang ist in beiden Fällen nicht so groß. Früher gabs das auch von so klassischen Navigationssoftware-Anbietern, die noch mit Daten CDs daher kam. Da konnte man dann ganze Adressen vervollständigen.
Ja, Google sollte man da vlt. besser außen vor lassen, das könnte zu Problemen führen.
ich bin auch der Meinung mich erinnern zu können, dass ich von einem Dozenten mal eine umfangreiche Datenbank erhalten hatte (gespeichert), die Plz und Orte in Deutschland umfasste, aber da müsste ich erstmal auf die Suche gehen.
Zitat von @Tomtom33:
Ja, Google sollte man da vlt. besser außen vor lassen, das könnte zu Problemen führen.
Ja, Google sollte man da vlt. besser außen vor lassen, das könnte zu Problemen führen.
Naja einfach machen und nicht erwähnen oder so.
Supercookies, TikTok etc. Interssiert sonst eh keinen. Musst halt aufpassen, mit wen du redest und erstmal Spass haben. Du fängst ja gerade erst an
Ich finde die DSGVO ziemlich gut geschrieben und sehr durchdacht. Es ist doch total simpel: Du brauchst einen Verarbeitungszweck in den der Dateninhaber eingewilligt hat. Entfällt der Zweck müssen die Daten gelöscht werden, solange dem kein Gesetz entgegen steht. Welches Vorgehen hier angemessen ist, entscheidet jeder selbst und dokumentiert das auch so.
Die DSGVO hat ihre Schatten Seiten aber sie deckt alles vernünftig ab, ist gut verständlich formuliert und schwafelt nicht groß rum.
Der Bezug zu den USA ist natürlich juristisch sehr komplex. Aus meiner Sicht ist bissher jeder Versuch, die US Gesetzgebung mit der EU-DSGVO zu vereinen, zu recht gescheitert und auch einfach unvereinbar. Wr das nicht wahr haben will macht sich selbst das Leben schwer, nicht die bösen Datenschützer ihm.
Die DSGVO hat ihre Schatten Seiten aber sie deckt alles vernünftig ab, ist gut verständlich formuliert und schwafelt nicht groß rum.
Der Bezug zu den USA ist natürlich juristisch sehr komplex. Aus meiner Sicht ist bissher jeder Versuch, die US Gesetzgebung mit der EU-DSGVO zu vereinen, zu recht gescheitert und auch einfach unvereinbar. Wr das nicht wahr haben will macht sich selbst das Leben schwer, nicht die bösen Datenschützer ihm.
Zitat von @ukulele-7:
Ich finde die DSGVO ziemlich gut geschrieben und sehr durchdacht. Es ist doch total simpel: Du brauchst einen Verarbeitungszweck in den der Dateninhaber eingewilligt hat. Entfällt der Zweck müssen die Daten gelöscht werden, solange dem kein Gesetz entgegen steht. Welches Vorgehen hier angemessen ist, entscheidet jeder selbst und dokumentiert das auch so.
Die DSGVO hat ihre Schatten Seiten aber sie deckt alles vernünftig ab, ist gut verständlich formuliert und schwafelt nicht groß rum.
Der Bezug zu den USA ist natürlich juristisch sehr komplex. Aus meiner Sicht ist bissher jeder Versuch, die US Gesetzgebung mit der EU-DSGVO zu vereinen, zu recht gescheitert und auch einfach unvereinbar. Wr das nicht wahr haben will macht sich selbst das Leben schwer, nicht die bösen Datenschützer ihm.
Ich finde die DSGVO ziemlich gut geschrieben und sehr durchdacht. Es ist doch total simpel: Du brauchst einen Verarbeitungszweck in den der Dateninhaber eingewilligt hat. Entfällt der Zweck müssen die Daten gelöscht werden, solange dem kein Gesetz entgegen steht. Welches Vorgehen hier angemessen ist, entscheidet jeder selbst und dokumentiert das auch so.
Die DSGVO hat ihre Schatten Seiten aber sie deckt alles vernünftig ab, ist gut verständlich formuliert und schwafelt nicht groß rum.
Der Bezug zu den USA ist natürlich juristisch sehr komplex. Aus meiner Sicht ist bissher jeder Versuch, die US Gesetzgebung mit der EU-DSGVO zu vereinen, zu recht gescheitert und auch einfach unvereinbar. Wr das nicht wahr haben will macht sich selbst das Leben schwer, nicht die bösen Datenschützer ihm.
Das ist natürlich Richtig, dass es ziemlich schwierig ist bei transatlantischen Beziehungen, oder eben außerhalb der EU (siehe bspw. Schweiz), nur Du kannst aber auch sehen, dass Google es ja selbst bestätigt, dass sie der DSGVO (wohl bemerkt in den EU-Mitgliedsländern) unterliegt, nach deiner Auslegung könnten sie ja auch sagen, wir richten uns nach dem Recht der USA, der Haken dabei ist aber, dass dann die EU ggf. ein Betätigungs-Verbot erwirken würde, also dass Google hier keine Geschäfte mehr machen darf, was ein schlagendes Argument sein dürfte.
Wie bereits erwähnt, gab es ja schon Verurteilungen gegen Google und Google musste horrende Strafen zahlen.
Anders herum würde Amerika genauso agieren, wenn bspw. eine deutsche Firma sich in Amerika auf das EU-Recht, oder das nationale Recht berufen würde. Sie doch einfach nur mal den Unterschied NIST und BSI, in Amerika sind bspw. Sozialversicherungsnummer äußerst sensibel gehandhabt, wenn sich eine deutsche Firma nicht an die Vorgaben halten würde, was glaubst Du passiert dann?
Ebenso bspw. die Haftungsfrage bei Incidents, in Deutschland haftet immer die Firmenleitung, in Amerika der mit der IT-Sicherheit Beauftragte MA - auch da könnte man ja dann sagen, wir arbeiten nach nationalem Recht - dürfte aber nicht funktionieren.
Stelle dir doch mal vor Du wärst Handelsreisender, der in Amerika Produkte an Kunden verkauft und deine Firma hat den Hauptsitz in Deutschland, welches Recht glaubst Du gilt für den Kaufvertrag, was für Steuerabgaben und Einfuhrzolle etc.?
Im letzten Fall wird es zugegeben recht kompliziert, zumal der Kaufvertrag dann in Amerika, mit einem amerikanischen Kunden stattfand, aber ist dann unser deutsches Recht, oder das EU-Recht anwendbar? - meines Erachtens nach nicht wirklich, denn sonst könnte ja auch jeder Chinese sagen, wir handeln nach unserem nationalen Recht, also keine Gewährleistung etc und und und.
Dazu gibt es dann meist Handelsabkommen (soweit überhaupt möglich), die das regeln sollen, welches Recht in welcher Situation zur Anwendung kommt - ich bin zwar kein Jurist, aber so ist zumindest in etwa der Ablauf.
Hält sich ein Handelspartner dann nicht an diese Übereinkünfte, dann gibt es Strafzölle, Einfuhrverbote und ggf. Betätigungsverbote, oder ähnliches als Druckmittel.
Also wie gesagt, auch wenn die theoretisch diese Möglichkeit hätten, heißt es noch lange nicht, dass es praktikabel wäre, denn bspw. ein Betätigungs-Verbot ist eine mächtige Waffe.
Ungeachtet dessen, kann man sich ein Bild von der Anwendbarkeit und den rechtlichen Grundlagen bezogen auf die DSGVO auch hier machen: Räumlicher Anwendungsbereich der DSGVO
Die DSGVO ist klar formuliert, hat aber auch ihre (juristischen) Lücken, das kann man nun so, oder so sehen.
Zitat von @Crusher79:
Naja einfach machen und nicht erwähnen oder so. Supercookies, TikTok etc. Interssiert sonst eh keinen. Musst halt aufpassen, mit wen du redest und erstmal Spass haben. Du fängst ja gerade erst an
Zitat von @Tomtom33:
Ja, Google sollte man da vlt. besser außen vor lassen, das könnte zu Problemen führen.
Ja, Google sollte man da vlt. besser außen vor lassen, das könnte zu Problemen führen.
Naja einfach machen und nicht erwähnen oder so.
Supercookies, TikTok etc. Interssiert sonst eh keinen. Musst halt aufpassen, mit wen du redest und erstmal Spass haben. Du fängst ja gerade erst an Richtige Einstellung 😁
@NamenlosChris
Da ich das nicht noch ein 2. Mal schreiben möchte, verweise ich diesen Beitrag von mir:
Eine Frage bezüglich Datenbank Normalisierung
Klar juristisch betrachtet gibt es Streitigkeit, das steht außer Frage, nur wenn Du meinen Kommentar dazu lesen würdest, dann fällt vlt. der Groschen, warum es eben auch Möglichkeiten gibt, eine andere ausländische Firma zur Einhaltung zu ... nennen wir es zwingen ..., auch wenn vlt. formal-juristisch der Sachverhalt anders aussehen könnte.
Bei diesen Streitigkeit geht es aber oft darum, in welchem Land Abgaben zu zahlen sind, oder ähnliches, also um ganz andere Themenbereiche, das blendest Du aber dabei aus.
Wie bereits beschrieben, schaue dir an was Google zur DSGVO, bezüglich "Recht auf Vergessen", schreibt ... und ja, auch dort ging ein Rechtsstreit voraus, in dem es aber u.A. um die Frage ging, ob das auch für Länder in Europa gilt, die nicht der EU angehören, während die Daten in einem EU-Land gehostet sind, was aber (natürlich) vom Gericht verneint wurde, da die betreffenden Daten der Kunden ja nicht dem EU-Recht für Verbraucher unterliegen.
Schwierig wird es wohl erst bei der Betrachtung, wenn personenbezogene Daten als Backup bspw. auf amerikanischen Servern landen, denn genaugenommen wäre das ein Datenschutz-Verstoß und die Daten wären ja auch nach einer Löschung theoretisch noch verfügbar, aber das ist sicher einer der Streitpunkte, die wirklich komplex werden - nur um es wenigstens mal erwähnt zu haben.
Erst Recht kompliziert wird es bei Plattformen wie Temu, wo die Kunden-Daten in China gehostet werden und auch der Firmensitz, die aber nur als Vermittler zu einzelnen Händlern auftreten. Es gilt zwar bei EU-Kunden (privat natürlich nur) die DSGVO 8siehe den anderen Beitrag), nur ob bei Verstößen eine Rechtverfolgung überhaupt möglich und umsetzbar ist, steht dann auf einem anderen Blatt Papier, denn da wird es wirklich schwierig, zumal man ja noch nicht einmal genau wissen kann, mit wem man da eigentlich Handel treibt, mal abgesehen davon, dass man als Kunde für die Einfuhrzölle verantwortlich ist.
Meine Meinung: wer dort Handel treibt geht ein hohes Risiko ein, denn neben datenschutzrechtlichen Bedenken kommen u.U. auch bspw. Steuerhinterziehung in Betracht (auch aus Unwissenheit und ohne eigenes verschulden), welche strafbar ist und sehr schnell, sehr teuer werden kann.
Man schaue sich dazu nur mal den Umgang Chinas mit der Datenerhebung seiner eigenen Bürger an, aber gut, dass ist ein anderes Thema.
Da ich das nicht noch ein 2. Mal schreiben möchte, verweise ich diesen Beitrag von mir:
Eine Frage bezüglich Datenbank Normalisierung
Klar juristisch betrachtet gibt es Streitigkeit, das steht außer Frage, nur wenn Du meinen Kommentar dazu lesen würdest, dann fällt vlt. der Groschen, warum es eben auch Möglichkeiten gibt, eine andere ausländische Firma zur Einhaltung zu ... nennen wir es zwingen ..., auch wenn vlt. formal-juristisch der Sachverhalt anders aussehen könnte.
Bei diesen Streitigkeit geht es aber oft darum, in welchem Land Abgaben zu zahlen sind, oder ähnliches, also um ganz andere Themenbereiche, das blendest Du aber dabei aus.
Wie bereits beschrieben, schaue dir an was Google zur DSGVO, bezüglich "Recht auf Vergessen", schreibt ... und ja, auch dort ging ein Rechtsstreit voraus, in dem es aber u.A. um die Frage ging, ob das auch für Länder in Europa gilt, die nicht der EU angehören, während die Daten in einem EU-Land gehostet sind, was aber (natürlich) vom Gericht verneint wurde, da die betreffenden Daten der Kunden ja nicht dem EU-Recht für Verbraucher unterliegen.
Schwierig wird es wohl erst bei der Betrachtung, wenn personenbezogene Daten als Backup bspw. auf amerikanischen Servern landen, denn genaugenommen wäre das ein Datenschutz-Verstoß und die Daten wären ja auch nach einer Löschung theoretisch noch verfügbar, aber das ist sicher einer der Streitpunkte, die wirklich komplex werden - nur um es wenigstens mal erwähnt zu haben.
Erst Recht kompliziert wird es bei Plattformen wie Temu, wo die Kunden-Daten in China gehostet werden und auch der Firmensitz, die aber nur als Vermittler zu einzelnen Händlern auftreten. Es gilt zwar bei EU-Kunden (privat natürlich nur) die DSGVO 8siehe den anderen Beitrag), nur ob bei Verstößen eine Rechtverfolgung überhaupt möglich und umsetzbar ist, steht dann auf einem anderen Blatt Papier, denn da wird es wirklich schwierig, zumal man ja noch nicht einmal genau wissen kann, mit wem man da eigentlich Handel treibt, mal abgesehen davon, dass man als Kunde für die Einfuhrzölle verantwortlich ist.
Meine Meinung: wer dort Handel treibt geht ein hohes Risiko ein, denn neben datenschutzrechtlichen Bedenken kommen u.U. auch bspw. Steuerhinterziehung in Betracht (auch aus Unwissenheit und ohne eigenes verschulden), welche strafbar ist und sehr schnell, sehr teuer werden kann.
Man schaue sich dazu nur mal den Umgang Chinas mit der Datenerhebung seiner eigenen Bürger an, aber gut, dass ist ein anderes Thema.