{"id":21835498,"url":"https://github.com/plopezgit/sprint2_t3_mongodb_data_structure","last_synced_at":"2025-10-10T20:33:34.275Z","repository":{"id":203055792,"uuid":"706639610","full_name":"plopezgit/Sprint2_T3_MongoDB_Data_Structure","owner":"plopezgit","description":"Flexible data structure comprehension","archived":false,"fork":false,"pushed_at":"2023-10-27T13:36:53.000Z","size":479,"stargazers_count":0,"open_issues_count":2,"forks_count":1,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-03-21T14:24:04.794Z","etag":null,"topics":["database","flexibility","mongodb","mongodb-collections","no-sql"],"latest_commit_sha":null,"homepage":"https://www.mongodb.com/","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/plopezgit.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-10-18T10:46:03.000Z","updated_at":"2023-10-27T17:55:40.000Z","dependencies_parsed_at":null,"dependency_job_id":"5b1da516-aca7-41e1-a1a1-8d439ea3d8f6","html_url":"https://github.com/plopezgit/Sprint2_T3_MongoDB_Data_Structure","commit_stats":null,"previous_names":["plopezgit/sprint2_t3_mongodb_data_structure"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/plopezgit/Sprint2_T3_MongoDB_Data_Structure","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/plopezgit%2FSprint2_T3_MongoDB_Data_Structure","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/plopezgit%2FSprint2_T3_MongoDB_Data_Structure/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/plopezgit%2FSprint2_T3_MongoDB_Data_Structure/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/plopezgit%2FSprint2_T3_MongoDB_Data_Structure/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/plopezgit","download_url":"https://codeload.github.com/plopezgit/Sprint2_T3_MongoDB_Data_Structure/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/plopezgit%2FSprint2_T3_MongoDB_Data_Structure/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":263061400,"owners_count":23407605,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["database","flexibility","mongodb","mongodb-collections","no-sql"],"created_at":"2024-11-27T20:21:34.042Z","updated_at":"2025-10-10T20:33:29.247Z","avatar_url":"https://github.com/plopezgit.png","language":"JavaScript","readme":"# Sprint2_T3_MongoDB_Data_Structure\n\nReading summary: **[task](https://github.com/plopezgit/Sprint2_T3_MongoDB_Data_Structure/issues/1#issue-1949444101)**\n\nLevel 1\n\nExercise 1\n\nAn optician wants to computerize customer management and glasses sales.\n\n_Solution 1: Reference relational model (strict validation scheme):_\n\n![Optic](src/n1Exe1/n1Exe1_model_references.png)\n\n_Solution 2: Enmbedded objects model:_\n\n![Optic](src/n1Exe1/n1Exe1_model_embeddedObjects.png)\n\n\nFirst of all, the optician wants to know the supplier of each of the glasses. Specifically, you want to know about each supplier:\n\n- Name.\n- The address (street, number, floor, door, city, postal code and country).\n- Phone.\n- Fax.\n- NIF.\n\nThe optician's purchasing policy is based on the fact that glasses from one brand will be purchased from a single supplier (this way you can get better prices), but they can buy glasses from several brands from one supplier. About the glasses he wants to know:\n\n\n- The brand.\n- The graduation of each of the crystals.\n- The type of frame (floating, paste or metallic).\n- The color of the frame.\n- The color of each crystal.\n- The price.\n\nFrom clients you want to store:\n\n- Name.\n- The postal address.\n- The phone.\n- The email.\n- The registration date.\n\nWhen a new customer arrives, store the customer who has recommended the establishment (as long as someone has recommended you).\n\nOur system must indicate who the employee who sold each eyeglass was.\n\n\n\nExercise 2\n\n\nYou have been hired to design a website that allows you to order food at home online.\n\n![Optic](src/n1Exe2/n1Exe2_model.png)\n\nTake into account the following indications to model what the project database would be like.\n\nFor each client we store a unique identifier:\n\n- Name.\n- Surnames.\n- Address.\n- Postal Code.\n- Location.\n- Province\n- Phone number\n\nThe locality and province data will be stored in separate tables. We know that a locality belongs to a single province and that a province can have many localities. A unique identifier and name are stored for each location. In each province we store a unique identifier and a name.\n\nOne person can place many orders, but a single order can only be placed by a single person. A unique identifier is stored for each order:\n\n- Date hour.\n- If the order is for home delivery or to pick up in store.\n- The number of products that have been selected of each type.\n- The total price.\n\nAn order can consist of one or more products.\n\nThe products can be pizzas, hamburgers and drinks. A unique identifier is stored for each product:\n\n- Name.\n- Description.\n- Image.\n- Price.\n\nIn the case of pizzas, there are several categories that can change names throughout the year. A pizza can only be in one category, but a category can have many pizzas.\n\nA unique identifier and name are stored for each category. An order is handled by a single store and one store can handle many orders. A unique identifier is stored for each store:\n\n- Address.\n- Postal Code.\n- Location.\n- Province.\n\nMany employees can work in one store and one employee can only work in one store. For each employee, a unique identifier is stored:\n\n- Name.\n- Surnames.\n- NIF.\n- Phone.\n\nIf you work as a cook or delivery person. For home delivery orders, it is important to save who the delivery person is who delivers the order and the date/time of delivery.\n\n\nLevel 2\n\nExercise 1\n\n![Optic](src/n2Exe1/n2Exe1_model.png)\n\n\nWe will try to make a simple model of what the database would be like for a reduced version of YouTube.\n\nWe store a unique identifier for each user: \n\n- E-mail.\n- Password.\n- Username.\n- Birthdate.\n- Sex.\n- Country.\n- Postal Code.\n\nA user publishes videos. For each video we save a unique identifier:\n\n- A title.\n- A description.\n- A size.\n- The name of the video file.\n- Video length. \n- A thumbnail. \n- The number of reproductions.\n- The number of likes.\n- The number of dislikes.\n\nA video can have three different states: public, hidden and private.\nA video can have many tags. \nA tag is identified by a unique identifier and a tag name.\nIt is interesting to save who the user is who publishes the video and what date/time they do so.\n\nA user can create a channel. A channel has a unique identifier:\n\n- A name.\n- A description.\n- A creation date.\n\nA user can subscribe to other users' channels.\nA user can like or dislike a video only once.\nIt will be necessary to keep a record of the users who have liked and disliked a certain video and what date/time they did so.\n\nA user can create playlists with the videos that she likes. Each playlist has a unique identifier:\n\n- A name.\n- A creation date.\n- A status indicating that it can be public or private.\n\nA user can write comments on a given video. Each comment is identified by a unique identifier:\n\n- The text of the comment.\n- The date/time it was done.\n\nA user can like or mark a comment.\n\nI don't like. A record will need to be kept of the users who have liked/disliked a comment, and what date/time they did so.\n\n\nLevel 3\n\nExercise 1\n\nWe will try to make a simple model of what the database needed for Spotify would be like.\n\n{soon}\n\nThere are two types of users: free and premium. \n\nWe store a unique identifier for each user:\n- Email.\n- password.\n- Username.\n- Birthdate.\n- Sex.\n- Country.\n- Postal Code.\n\nPremium users make subscriptions. The necessary data that must be saved for each subscription is:\n\n- Subscription start date.\n- Service renewal date.\n\nA form of payment, which can be by credit card or PayPal.\nFor credit cards we store the card number, month and year of expiration and the security code. For users who pay with PayPal, we save the PayPal username. We are interested in keeping a record of all the payments that a premium user has made during the period they are subscribed to. \n\nFrom each payment is saved:\n- The date.\n- An order number (which is unique).\n- A total.\n\n\nA user can create many playlists. From each playlist we save:\n- A title.\n- The number of songs it contains.\n- A unique identifier.\n- A creation date.\n\nWhen a user deletes a playlist it is not deleted from the system, but rather it is marked as having been deleted. This way the user can recover her playlists in case they have deleted them by mistake. It is necessary to store the date on which the playlist was\nbeen marked as deleted.\n\nWe can say that there are two types of playlists: active and deleted. A playlist that is active can be shared with other users, this means that other users can add songs to it. In a shared list we are interested in knowing which user added each song and on what date they did so.\n\nA song can only belong to a single album. An album can contain many songs. An album has been published by a single artist. An artist may have published many albums. For each song we save a unique identifier:\n\n- A title.\n- A duration.\n- The number of times it has been played by Spotify users.\n- For each album we save a unique identifier:\n- Qualification.\n- Year of publication.\n- An image with the cover.\n\nWe keep a unique identifier for each artist:\n- Name.\n- An image of the artist\n\nA user can follow many artists. An artist can be related to other artists who make similar music. So Spotify can show us a list of artists related to the artists we like. We are also interested in saving a user's favorite albums and songs. \n\nA user can select many albums and many songs as favorites.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fplopezgit%2Fsprint2_t3_mongodb_data_structure","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fplopezgit%2Fsprint2_t3_mongodb_data_structure","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fplopezgit%2Fsprint2_t3_mongodb_data_structure/lists"}