feat: improved data structure docs

README.md

@@ -112,131 +112,39 @@ obj -> pg: if available download audio to target.
 
 ## Data Model
 
-The Data Structure, that the whole programm is built on looks as follows:
+Music metadata can be easily abstracted to a few main Entities with some relations between them. This enables the easy scraping and aggregation of the correct metadata for each Song. Those Entities are `Song`, `Album`, `Artist` and `Label`.
+
+<details>
+This is convenient because then I can just use for example one Artist, which adds its metadata shared and consistently to each of its song. This exactly was the reason why piracy was such a mess in the past. Metadata has a lot of redundancy, but the relational databases of streaming services don't. THIS is the main reason for this program, and in my opinion also the reason for the widespread adoption of streaming services.
+</details>
 
 ```mermaid
 ---
-title: Music Data
+title: music kraken - data model
 ---
 erDiagram
 
+Song {}
+Album {}
+Artist {}
+Label {}
 
+Song ||--o{ Album : album_collection
+Song ||--o{ Artist : main_artist_collection
+Song ||--o{ Artist : feature_artist_collection
 
-Target {
+Album ||--o{ Song : song_collection
+Album ||--o{ Artist : artist_collection
+Album ||--o{ Label : label_collection
 
-}
+Artist ||--o{ Song : feature_song_collection
+Artist ||--o{ Album : main_album_collection
+Artist ||--o{ Label : label_collection
 
-Lyrics {
-
-}
-
-Song {
-
-}
-
-Album {
-
-}
-
-Artist {
-
-}
-
-Label {
-
-}
-
-Source {
-
-}
-
-Source }o--|| Song : ""
-Source }o--|| Lyrics : ""
-Source }o--|| Album : ""
-Source }o--|| Artist : ""
-Source }o--|| Label : ""
-
-Song }o--o{ Album : AlbumSong
-Album }o--o{ Artist : ArtistAlbum
-Song }o--o{ Artist : "ArtistSong (features)"
-
-Label }o--o{ Album : LabelAlbum
-Label }o--o{ Artist : LabelSong
-
-Song ||--o{ Lyrics : ""
-Song ||--o{ Target : ""
-```
-
-Ok now this **WILL** look intimidating, thus I break it down quickly.  
-*That is also the reason I didn't add all Attributes here.*
-
-The most important Entities are:
-
-- Song
-- Album
-- Artist
-- Label
-
-All of them *(and Lyrics)* can have multiple Sources, and every Source can only Point to one of those Element.
-
-The `Target` Entity represents the location on the hard drive a Song has. One Song can have multiple download Locations.
-
-The `Lyrics` Entity simply represents the Lyrics of each Song. One Song can have multiple Lyrics, e.g. Translations.
-
-Here is the simplified Diagramm without only the main Entities.
-
-
-```mermaid
----
-title: simplified Music Data
----
-erDiagram
-
-Song {
-
-}
-
-Album {
-
-}
-
-Artist {
-
-}
-
-Label {
-
-}
-
-Song }o--o{ Album : AlbumSong
-Album }o--o{ Artist : ArtistAlbum
-Song }o--o{ Artist : "ArtistSong (features)"
-
-Label }o--o{ Album : LabelAlbum
-Label }o--o{ Artist : LabelSong
+Label ||--o{ Album : album_collection
+Label ||--o{ Artist : current_artist_collection
 
 ```
 
-Looks way more manageable, doesn't it? 
-
-The reason every relation here is a `n:m` *(many to many)* relation is not, that it makes sense in the aspekt of modeling reality, but to be able to put data from many Sources in the same Data Model.  
-Every Service models Data a bit different, and projecting a one-to-many relationship to a many to many relationship without data loss is easy. The other way around it is basically impossible
-
-## Data Objects
-
-> Not 100% accurate yet and *might* change slightly
-
-### Creation
-
-```python
-# needs to be added
-```
-
-
-
-If you just want to start implementing, then just use the code example I provided, I don't care.  
-For those who don't want any bugs and use it as intended *(which is recommended, cuz I am only one person so there are defs bugs)* continue reading, and read the whole documentation, which may exist in the future xD
-
-
 [i10]: https://github.com/HeIIow2/music-downloader/issues/10
 [i2]: https://github.com/HeIIow2/music-downloader/issues/2