Todays focus is on the backend part of your application. You will be expected to produce UML diagrams for a data model that you have designed. You should also be able to implement your design, and seed it with data.
Data is fundamental to every application. The whole purpose of the interface layer is to enable users to interact with the data.
Get this right everything should slot into place nicely. Get this wrong you can end up with an app that fights itself and is a pain to work with.
From module 3 you will be thinking to yourself about the design phase. Can you remember the following:
In a database that uses schemas the data points you want to store are defined in a schema. If you try to store data that does not match the schema - you'll be in trouble. Below is an example of a schema definition.
CommunityEvent.init({
title: DataTypes.STRING,
desc: DataTypes.STRING,
datetime: DataTypes.DATE,
spaces: DataTypes.INTEGER
}, { sequelize, modelName: 'event' })
Our schema defines what a community event's properties are. How many different 'types' (i.e. STRING, DATE) are we able to store?
{
title: "10 pin bowling",
desc: "Come and join us for 3 frames Friday at the Elephant",
datetime: "2020-10-31T20:30:00.000Z",
spaces: 16,
rsvp: 9
}
❓ Can we store the event above?
Data design is thinking about what you are going to store. Storing simple data points is straight forward. What is more interesting is storing the way simple data points are related to each other.
The types of relationships between entities in our data model can be HasMany or BelongsTo. For example an event Has Many bookings. A booking Belongs To an event.
The way to relate data together in schema based datasets is to use the primary id of one record in another record. The name for the field you use to store another record's primary id is the foreign key. Referencing the primary key and foreign key in a query joins the two records together.
For example:
Here the id of an event row is stored in a bookings row under the event_id field. With this kind of data design we can query for an event and count all it's related bookings:
SELECT events.title, COUNT(bookings.id) as bookings
FROM events
JOIN bookings ON event.id = bookings.event_id
WHERE events.date > GETDATE();
Schemaless datastores like MongoDB give you an alternative way to store the relationships between your data points. In a document store in place of tables there are schemaless "collections". Each item in a collection is considered a "document" and they can have nested data points.
For example we could have an events collection, and store our events as documents. Each event could have a bookings field that stored an array of booking objects.
This looks much easier to deal with, and it is until we want to count all the bookings across all the events. Then we have to query all the events, and sum all the bookings properties across those events.
Both ways of storing the relationships are effective. Depending on they way you'll need to retrieve your data you might choose one over the other. You can represent BOTH kinds of data using UML entity diagrams. So our document store version of events and bookings might look like this:
Most frameworks will have a way for you to auto generate entities and the relationships between them. Some libraries require you to declare your models and the relationships between them.
This is a really good candidate for some tests. You want to use tests to ensure you have set up the data model correctly that that all the relationships are correct.
Can you create a data design for your chosen synoptic project? Read the brief carefully and think about what needs to be captured from the use, what needs to be stored and how you will persist the relationships between different data points.