Did you read the part about posting DDL on SQL forums? Your useless picrure is not RDBMS, but the usual beginner's version of a dimensional schema. One of the basic rules of data modeling is a data element name does not contain metadata, like "_key" or "dim_" because the data element name should tell us what something is not how it is used in a particular instance. Since we have no DDL. We have no idea how these pictures of tables are related. Nor do we have any constraints. Perhaps you should read a book?
CREATE TABLE Personnel
(emp_id CHAR(10) NOT NULL PRIMARY KEY,
emp_first_name VARCHAR(20) NOT NULL,
emp_last_name VARCHAR(20) NOT NULL);
Since the table models a set of entities, its name has to be a plural or collective noun in a valid model. Did you notice that there's a key to the table? And it has to be declared in the DDL not in the name.
CREATE TABLE Customers
(cust_id CHAR(10) NOT NULL PRIMARY KEY,
cust_first_name VARCHAR(20) NOT NULL,
cust_last_name VARCHAR(20) NOT NULL,
cust_phone_nbr CHAR() CHECK (cust_phone_nbr LIKE ...'));
Technically, putting the phone number in with the customers de-normalizes your schema. A customer has a relationship with the phone number I can have more than one or none at all. Also, if you're going to actually store phone numbers you need to have a string of digits that conforms to the international standards for phone numbers and is enforced in the a regular expression.
CREATE TABLE Products
(product_gtin CHAR(15) NOT NULL PRIMARY KEY,
product_name VARCHAR (35) NOT NULL,
unit_price DECIMAL (12,2) NOT NULL);
Products should be identified by an industry-standard encoding; I happen to like the global trade item number (GTIN), but you should use whatever your industry standards are. Prices can be an aggregate, retail, wholesale, or by units or other ways. When naming a data element, be specific. I'm going to assume these are unit prices, and there is some standard of measure in which your products are sold. That's probably wrong, since things like mulch and seeds can come in different packaging but we don't have much to work with here.
Finally, if that was intended to be a table of Transactions, it's completely wrong. A transaction needs a date, a seller, buyer and and a product. Why do you think that "value" is a clear and precise term. It's immediately obvious to anyone reading this? NO! What does a negative value mean? Did you know that the word VALUE is a reserved word in ANSI/ISO standard SQL? A transaction is an activity, so each transaction should have a date. Why did you split things apart?
CREATE TABLE Tranactions
(emp_id CHAR(10) NOT NULL
cust_id CHAR(10) NOT NULL
product_gtin CHAR(15) NOT NULL
transaction_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
PRIMARY KEY (emp_id, cust_id, product_gtin, transaction_date),
Now your little homework problem becomes immediately obvious. You will find the next couple of months. As you learn SQL and RDBMS, that most of the work is done in the DDL and not in absurd pictures of tables from spreadsheets. You will have an epiphany in which you realize that using integers to create 1960s pointer chains is not relational. Currently, your mindset is completely wrong.
Please post DDL and follow ANSI/ISO standards when asking for help.