Assignment: The entity-relationship data model

COMPSCI 2DB3: Databases – Winter 2024

Deadline: February 26, 2024
Student number: 400430396
Mac ID: mokhasus

Part one: The online Market

Part one consists of both a rational for the solution and the solution itself.

Rational:
For the first step, we analyse the description of the ER-diagram given to us in Figure 1 to find relevant

information for our translation. In the analysis, the following text annotations are being used:

an entity The highlighted piece of text resembled an entity-like object.

an attribute The highlighted piece of text resembled an attribute of some entity-like object.

a relationship The highlighted piece of text resembled a relationship between entity-like objects.

a constraint The highlighted piece of text resembled a constraint on data.

not-relevant The highlighted piece of text is not relevant (e.g., context, application details, ...)

Following is the original description:

Local farmers are discussing setting up an online co-op farmers market to make healthy in-season produce

directly available to consumers for fair prices for both consumers and the farmers. In addition, the farmers

market should provide a review system for produce. To figure out the requirements of building such a system,

the farmers have contacted a consultant that provided some initial design on the data model of the online

market and review system.

To enable a farmers market, the farmers are looking into setting up a digital market place.

In this marketplace, we have two types of users: consumers and producers. Producers can also partake

in the system as consumers (of produce of other producers). All users can log in to their account via their

unique e-mail address and a password. Consumers have a delivery address. Producers have a public seller

name and need to be vetted by the co-op to assure that only legitimate farmers are providing their produce.

In addition, producers can put up offers for produce. Producers can place active orders every week of the

year and offers expire after a week. Consumers can place orders in which they buy one-or-more offers at a

given date (which should fall within the week in which all parts of the sale are active).

The ER-Diagram for the online market can be found in Figure 1.

We will use this information collected in the analysis in our solution.

Solution:

We start with the User entity as it is not a weak entity. It has 3 attributes mid, email and password out of which
mid is the primary key. It was also mentioned in the description that the email and password need to be unique
and hence I have used the keyword UNIQUE to enforce that constraint. Primary key of an entity is unique by
default and hence does not need the UNIQUE keyword to constrain it.

I have used INT type for mid as it would create unique IDs, and VARCHAR(100) for both email and password as
that will allow the user to use different characters in their email and password and at the same time restrict it to
100 characters. As all the attributes here are mandatory, I have assigned them to be NOT NULL.

User (mid: INT, email: VARCHAR (100), password: VARCHAR (100))

The user schema translates to the following SQL statement:

CREATE TABLE user(

mid INT NOT NULL PRIMARY KEY,

email VARCHAR(100) NOT NULL UNIQUE,

password VARCHAR(100) NOT NULL UNIQUE

);

The User entity is in an ISA relationship with Producer and Consumer entities. We will go through the Producer
entity first to maintain a flow through the ER diagram provided.

I have again used mid as a foreign key from user to be the Primary key in Producer entity as shown below. I also
used the datatype CLOB for name as it accommodates unicode-character based data which allows users to enter
their names in their respective text styles without any certain restriction on the number of characters that can be
used. As all the attributes in the Producer entity are also mandatory, I have assigned to be NOT NULL.

Producer (mid: INT, name: CLOB)

The producer schema translates to the following SQL statement:

CREATE TABLE producer(

mid INT NOT NULL,

name CLOB NOT NULL,

FOREIGN KEY(mid) REFERENCES user,

PRIMARY KEY(mid)

);

Next we go through the Produce entity. This has 3 attributes called pid, name and description. I have used INT
for pid which is also the primary key of the corresponding table, CLOB for name and description.

Produce (pid: INT, name: CLOB, description: CLOB)

The Produce schema translates to the following SQL statement:

CREATE TABLE produce(

pid INT NOT NULL,

name CLOB NOT NULL,

description CLOB NOT NULL,

PRIMARY KEY(pid)

);
Next we move to the Offer entity which is a weak entity as it depends on both Producer and Produce entities. It
has the attribute week as its weak primary key and price as its other attribute. But apart from these both
attributes it also inherits the primary keys from the Producer and Produce entities. As a result, Offer has 3
primary keys pid, mid and week.

I have assigned price to be of DECIMAL type for easier accommodation of dollars and cents and week as INT. mid
and pid are Foreign keys and I have referenced them accordingly. As all the attributes are mandatory, I have
assigned them to be NOT NULL.

Offer (mid: INT, pid: INT, week: INT price: DECIMAL)

The Offer schema translates to the following SQL statement:

CREATE TABLE offer(

mid INT NOT NULL,

pid INT NOT NULL,

week INT NOT NULL,

price DECIMAL NOT NULL,

FOREIGN KEY(mid) REFERENCES user(mid),

FOREIGN KEY(pid) REFERENCES produce(pid),

PRIMARY KEY(pid, mid, week)

);

Next we move on to the Sale entity which is in a one-to-many relationship with Consumer entity. This entity has
its own primary key called sid of INT type and has another attribute called date of DATE type. As both its
attributes are mandatory, I have assigned them to be NOT NULL.

Sale (sid: INT, date: DATE)

The Sale schema translates to the following SQL statement:

CREATE TABLE sale(

sid INT NOT NULL,

date DATE NOT NULL,

PRIMARY KEY(sid)

);

As mentioned above, the Sale entity is in a one-to-many relationship with the Consumer entity. It uses a foreign
key from User through the ISA relationship and has another attribute called address of datatype VARCHAR(200)
which keeps track of the address of the consumer. As it uses mid as a foreign key, I have referenced it accordingly.

Consumer (mid: INT, address: VARCHAR (200))

The Consumer schema translates to the following SQL statement:

CREATE TABLE consumer(

mid INT NOT NULL,

address VARCHAR(200) NOT NULL,

FOREIGN KEY(mid) REFERENCES user(mid),

PRIMARY KEY(mid)

);
Finally, we get to the BOffer relationship which has an attribute of its own called amount of type DECIMAL.
However, this relationship gets the primary keys of all the other entities of the ER diagram as it helps in
maintaining consistency. Therefore, the entity Boffer has the attributes sid, mid, pid, week and amount out of
which pid, mid, sid and week are the primary keys. I have referenced them accordingly as most of the attributes
are foreign keys from other entities. As all the attributes are mandatory, I have assigned them to be NOT NULL.

BOffer (sid: INT, mid: INT, pid: INT, week: INT, amount: DECIMAL)

The BOffer schema translates to the following SQL statement:

CREATE TABLE boffer(

mid INT NOT NULL,

pid INT NOT NULL,

sid INT NOT NULL,

week INT NOT NULL,

amount DECIMAL NOT NULL,

FOREIGN KEY(mid) REFERENCES user(mid),

FOREIGN KEY(pid) REFERENCES produce(pid),

FOREIGN KEY(sid) REFERENCES sale(sid),

PRIMARY KEY(pid, mid, sid, week)

);

Part two: The review system

Foreword
I have used mid instead of uid as mentioned in the description of each subpart in Part two as uid and mid both

refer to the same value in the table. Keeping the name as mid instead of changing it to uid simplifies the

translation of SQL statements.

Description
In addition, users can review produce they have ordered before. Reviews can be either short form (a score) or

long form (a score with a description). The consultant sketched the following layout of the database maintaining

these reviews, but indicated that some details still need to be figured out:

▶ A table Review (rid, sid, uid, score, date, descriptionoptional).

This table provides a basic review with identifier rid. The review is on the sale identified by sale

identifier sid and is written by the user with user identifier uid (which can be either the consumer or a

producer that partook in the sale). Every review has a score and a date of writing. In addition, reviews

can optionally have a long-form description.

Solution:
We only need to translate the given schema into SQL statements. I have used INT type for score and DATE type
for date and CLOB type for description. I have also marked description to be NULL as it is an optional attribute.
The simples approach to do so is:

CREATE TABLE review(

rid INT NOT NULL,

sid INT NOT NULL,

mid INT NOT NULL,

score INT NOT NULL,

date DATE NOT NULL,

description CLOB NULL,

FOREIGN KEY(sid) REFERENCES sale(sid),

FOREIGN KEY(mid) REFERENCES user(mid),

PRIMARY KEY(rid)

);

▶ A table ReviewVote (rid, uid, voteType)

This table provides votes on the usefulness of reviews. All users (consumers and producers) can vote

whether a review is helpful or not. In this table, rid refers to a review, uid refers to a user, and voteType

can represent an upvote, neutral, or a downvote.

Solution:

We only need to translate the given schema into SQL statements. I have referenced the foreign keys accordingly
and used VARCHAR(10) for voteType attribute which allows the user to either upvote, downvote or stay neutral
about their preference.

CREATE TABLE reviewvote(

rid INT NOT NULL,

mid INT NOT NULL,

votetype VARCHAR(10),

FOREIGN KEY(rid) REFERENCES review(rid),

FOREIGN KEY(mid) REFERENCES user(mid),

PRIMARY KEY(rid, mid)

);

▶ A view SellerScore (pid, score, num_reviews) to easily retrieve a summary of all reviews for a producer:

the summary should contain the average score the sales of the producer received and the number of

reviews the sales of the producer have received. For this review, we only consider reviews on sales

written by the consumer that placed the sale.

Solution:

We only need to create the specified view, which can be created using the following SQL query.
 CREATE VIEW SellerScore AS

SELECT p.mid AS pid, AVG(r.score) AS score, COUNT(r.rid) AS

num_reviews

FROM Review r

JOIN Sale s ON r.sid = s.sid

JOIN BOffer b ON s.sid = b.sid

JOIN Producer p ON b.mid = p.mid

GROUP BY p.mid;

▶ The consultant wants a table comment that can store user content for produce. Each comment should

have a title (e.g., “great for summer salads”) and a description (e.g., a summer-salad recipe). Each

comment is written by a user on a given date and a user can write multiple comments. Users can not

only put comments directly on produce, but also react on the comments of other users.

Solution:

The table comment makes a many-to-many relationship with User and Produce entities. Hence its schema needs
to be structured as follows:

Comment( cid: INT, mid: INT, pid: INT, date: DATE, title: CLOB, description: CLOB, reactiontype:
VARCHAR(20))

The Comment schema translates to the following SQL statement:

CREATE TABLE comment(

cid INT NOT NULL,

mid INT NOT NULL,

pid INT NOT NULL,

date DATE NOT NULL,

title CLOB NOT NULL,

description CLOB NOT NULL,

reactiontype VARCHAR(20) NULL,

FOREIGN KEY(mid) REFERENCES user(mid),

FOREIGN KEY(pid) REFRENCES produce(pid),

PRIMARY KEY(cid)

);

▶ A constraint that reviews are only written by either the consumer or a producer that partook in the

sale that is reviewed.

Solution:

This constraint cannot be expressed without using a multi-table constraint.