1. Translate the following business rules into an object relational diagram (ORD) using UMLet (See the above Object Relational Diagram examples).
   • a USER has many ROLES.
   • a USER has one BIRTHDATE.
   • a USER can have many DEPENDENTS.
2. Convert the translated diagrams into NoSQL data structures (see pages 15-18).
3. Save the ORD and NoSQL data structure as separate image files.

 

Transcribed Image Text:

For this week's assignment we will be comparing and contrasting the differences between relational and non-relational database structures. Relational databases have been a successful technology for over twenty years, providing persistence, concurrency control, and an integration mechanism (Fowler & Sadalage, 2012). Data persistence, as the name suggests, is the process of "persisting" data to some physical location. The popularity of relational databases derives from its ability to "make-sense" of complex data structures. Data is categorized into tables, columns, and rows. Tables represent the entities (think JavaScript classes), columns represent the Meta data (think JavaScript properties), and rows are the raw data elements (think values). There are three types of relationships in a relational database system, One-to-Many, Many-to-Many, and One-to-One. Business rules are brief, precise, and unambiguous descriptions of a policy, procedure, or principle within an organization. Diagrams are used to graphically illustrate these business rules and their associated relationships. One-to-Many Relationship Many-to-Many Relationship One-to-One Relationship Business Rule: a PERSON can own many CARS Business Rule: an EMPLOYEE can learn many SKILLS Business Rule: an EMPLOYEE manages one RESTAURANT Object Relational Diagram Object Relational Diagram Object Relational Diagram SKILL EMPLOYEE RESTAURANT owing kams L manages 1.1 1.1 There is a movement away from using databases as integration points towards encapsulating databases within applications and integrating through services (Fowler & Sadalage, 2012). This gravitation has resulted in the adoption and evolution of NoSQL database structures. Web communications and transmissions are unstructured data components that require a mechanism for dealing with their complexities. NoSQL technologies bridge this gap by not forcing developers into specific paradigms, rather allowing them to keep the data generic and language agnostic. In a NoSQL world, the above diagrams data structure may resemble the following: NoSQL Data Structure: "first_name": "Martin", "last_name": "Fowler", "cars": [ { "type": "Ford", "color": "White" }, { "type": "Nissan", For this week's assignment we will be comparing and contrasting the differences between relational and non-relational database structures. Relational databases have been a successful technology for over twenty years, providing persistence, concurrency control, and an integration mechanism (Fowler & Sadalage, 2012). Data persistence, as the name suggests, is the process of "persisting" data to some physical location. The popularity of relational databases derives from its ability to "make-sense" of complex data structures. Data is categorized into tables, columns, and rows. Tables represent the entities (think JavaScript classes), columns represent the Meta data (think JavaScript properties), and rows are the raw data elements (think values). There are three types of relationships in a relational database system, One-to-Many, Many-to-Many, and One-to-One. Business rules are brief, precise, and unambiguous descriptions of a policy, procedure, or principle within an organization. Diagrams are used to graphically illustrate these business rules and their associated relationships. One-to-Many Relationship Many-to-Many Relationship One-to-One Relationship Business Rule: a PERSON can own many CARS Business Rule: an EMPLOYEE can learn many SKILLS Business Rule: an EMPLOYEE manages one RESTAURANT Object Relational Diagram Object Relational Diagram Object Relational Diagram SKILL EMPLOYEE RESTAURANT owing kams L manages 1.1 1.1 There is a movement away from using databases as integration points towards encapsulating databases within applications and integrating through services (Fowler & Sadalage, 2012). This gravitation has resulted in the adoption and evolution of NoSQL database structures. Web communications and transmissions are unstructured data components that require a mechanism for dealing with their complexities. NoSQL technologies bridge this gap by not forcing developers into specific paradigms, rather allowing them to keep the data generic and language agnostic. In a NoSQL world, the above diagrams data structure may resemble the following: NoSQL Data Structure: "first_name": "Martin", "last_name": "Fowler", "cars": [ { "type": "Ford", "color": "White" }, { "type": "Nissan",