I have a Jekyll project that contains products (in a collection). Each product has a company, which is a reference to an entity in the companies collection. Each company then has its own properties (for the sake of the example, let's say it has a country property).
How can I list products and group them by the company's country? Can I "project" the company's properties on the collection I'm actually working with (in this case, the products collection)? Or am I limited to properties of the collection being enumerated?
I have a particular problem from my assignment which goes like this :
"Each product making up a set is supplied by a single supplier and is given a unique ID,. Products are always sold as part of a set, never on their own."
So based on this is assumed Many Products creates One Package(aka set), but i don't know if i'm right, if so how can I visually show a Many to One relationship as an ER diagram.
I have constructed my own Conceptual and Logical ER diagram, I just need to know if i'm right or wrong so that i can continue with the rest.
Here's a breakdown of the assignment and what I get from it:
Each product making up a set is supplied by a single supplier and is given a unique ID,. Products are always sold as part of a set, never on their own.
From this I get that we have these entities:
Product
Supplier
Package (Set)
You should know that each Entity needs its own primary key. Pros will either call this id, or product_id. There are ORM's that tend to work best out of the box, if you name the pk for each table 'id', especially when it is a simple sequence number.
It's also better not to do what you are doing with attribute names. In sql people stick with either all uppercase or all lowercase naming rather than camelcase. Also I'd suggest that you don't name the price attribute pPrice just because it's in the Package table. Just name it price, because it can be referred to as Package.price if you need to tell it apart from some other table that also contains a price column.
The important thing to understand is that the relationship between Package and Product is Many to Many
One Product can be part of Many Packages.
One Package can contain Many Products
In order to create entities for a Many to Many relationship, you need a table that sits between the 2 tables and will have foreign keys to both tables in it. Typically people will pick whatever they consider the dominant side -- I would probably use Package, and name the table "PackageProduct" to reinforce the idea that this table lets me package products together and sell or distribute them.
PackageProduct
--------------
id (pk)
package_id (foreign key to Package table)
product_id (foreign key to Product table)
You also need a supplier table, but you were informed that the relationship between Package and supplier is that a Package can have one and only one Supplier.
This is code for: create a one to many relationship between Supplier and Package. In doing this, Package will have a foreign key in it that stores the Supplier.id (or supplier_id)
So to conclude you should have these entities (tables):
Package
Product
Supplier
PackageProduct
ERD
Here's an ERD rendered with "Relational" format which I find a bit more descriptive, as the many sides of the connections use the crowsfoot, so it's very obvious.
According to your description your schema will have one to many relation i.e your single package comprises many products.
You can also find out your ERD diagram
Is this a circular reference? If so, how can I improve my model?
You don't have any circular references. I interpret the data model to say:
An Item belongs to exactly 1 Client
An Item belongs to 0 or 1 Employee
An Employee belongs to exactly 1 Client
A circular reference would add An Employees to exactly 1 Item.
In the comments, you said than an item always belongs to the same client as it's employee, but not all items belong to an employee.
There are a few ways to model this.
What I would avoid is having ClientID as a not-null foreign key relationship on Item - this duplicates the logic that "an item without an explicit client ID inherits the client ID from its employee". It's not expressive (people reading the schema would not be able to figure that out), and opens up bugs.
One option is to make the cardinality of both item->employee and item-> client optional (i.e. 0..1). Your convention would then be if an item has a client relationship, it may not have an employee relationship, and if an item has an employee relationship, it may not have an explicit client relationship; the client is determined by the employee. You can't cleanly express this in your schema, and would have to build this into your data access code.
Another option is to create two type of item, one with a clientID foreign relationship, and one with an employeeId foreign relationship. This is much more expressive from a schema point of view - presumably there is some business concept you can use to name the tables. However, if Item has lots of attributes, you're duplicating a lot.
Finally, you could store the relationship of items to either client or employee in separate joining table:
Item
-------
ItemID
...
ItemEmployees
-----------------
ItemID
EmployeeID
ItemClients
----------
ItemID
ClientID
This avoids the duplication of attributes on Item, but is less expressive because it uses a pattern more commonly used for many-to-many relationships, and doesn't explicitly declare "either or".
TABLE FIELDS
users user_id
items item_id
item_instance item_inst_id
item_inst_qty
user_id
item_id
The first table has all the users, and the second table has all the items.
The third table records the quantity of a specific item which a user has. It is not recording data about the item itself, but rather the data about the relationship between the item and user.
My question is what is the third type of table generally referred to as? The most accurate abstraction I could think of is "instance," as taken from OOP, because each data record represents an occurrance of a particular class of data, which in this case is the "item" class. Also, "case" was another possiblity.
In database programing, is there a generally accepted term for a table which has records that tie two tables together in this manner? Or is the naming convention usually up to the programmer? If the latter, what is your take?
First module is User module. Administrators, students, lecturers or guests are users who benefit from the system and they take part in this module. Administrator will assign role as student or lecturer for each user. Each role has different privileges that is lecturer can upload the assignment and course materials, create the online quiz and single upload file. Users have information such as user ID, date of registration, date of latest logon, login account, password, first name, last name, and others details needed. Just say that student ID and lecturer ID cannot be the primary key. Therefore, how am I suppose to state that assignment or quiz ID is functionally dependent on lecturer when assignment ID and my quiz ID is a primary key? Based on my functional dependency, I'm not really sure how am I suppose to relate them to functional dependency?
Entity: User
User(user ID, student ID, lecturer ID, guest ID, course ID, assignment ID, quiz ID, file upload, date of registration, date of latest logon, login account, password, first name, last name, e-mail, birthdate)
Functional dependency
user ID -> {student ID, lecturer ID, guest ID, date of registration, date of latest logon, login account, password, first name, last name, e-mail, birthdate}
lecturer ID -> {course ID, assignment ID, quiz ID, file upload}
Full dependency
user ID, lecturer ID -> {student ID, guest ID, course ID, assignment ID, quiz ID, file upload, date of registration, date of latest logon, login account, password, first name, last name, e-mail, birthdate}
First, a functional dependency in the form A->B means that, given one value for A, we can determine one and only one value for B. Both A and B represent sets of columns. (That's why they're written in uppercase letters.)
Keys really have nothing to do with how you state a functional dependency.
If "lecturer id" functionally determines "assignment id" then the FD is "lecturer id"->"assignment id". If "lecturer id" also functionally determines "quiz id", then another FD is "lecturer id"->"quiz id".
If you want to write that more compactly, you can state the two FDs like this.
"lecturer id"->{"assignment id", "quiz id"}
If you assign the letters L, A, and Q, you can state the two FDs like this.
L->AQ
Braces are usually omitted in this notation, because everyone knows they're supposed to be there.
I'm not sure what you're trying to get at with your last section. But in it, the section labelled "Functional Dependency" doesn't express any dependencies; "Full dependency" doesn't express full dependencies, but might express some partial dependencies; "Partial dependencies" doesn't express any partial dependencies; "Transitive dependencies" doesn't express any transitive dependencies.
It is not clear what you are trying to accomplish. And you don't seem to understand the steps that we go through in schema design.
First we determine what application relationships we are interested in. Eg "user [userID] has role lecturer" or "user [user ID] has first name [first name] and password [password] and ...". Each gets a base relation that holds the rows of values that are related that way.
For each relation the meaning of its application relationship determines for every column what sets of columns it is functionally dependent on. Then we find a minimal cover for that. This determines candidate keys. We can pick one candidate key as primary key.
This determines full and partial dependencies of non-prime columns on each candidate key. This allows us to normalize to 2NF by decomposing our relation to separate the non-prime column partial functional depencies on candidate keys into separate relations.
Just say that student ID and lecturer ID cannot be the primary key.
Therefore, how am I suppose to state that assignment or quiz ID is
functionally dependent on lecturer when assignment ID and my quiz ID
is a primary key?
This doesn't make sense. We can't determine the candidate keys until we determine all the functional dependencies. Also: Do you mean {studentID,lecturerID} "can't be the primary key", or do you mean {student ID} "can't" and {lecturer ID} "can't"? Also: What do you mean by "can't"?
We say assignmentID and quizID are functionally dependent on lecturerID in some relation by:
{lecturer ID} -> {assignment ID}
{lecturer ID} -> {quiz ID}
We can combine right hand sides (determined column sets) with the same left hand side set (determiner):
{lecturer ID} -> {assignment ID, quiz ID}
But there other rules like that for finding a minimal cover.
Based on my functional dependency, I'm not really sure how am I
suppose to relate them to functional dependency?
This doesn't make sense. Relate what to your functional dependencies?
If the only functional dependencies for "User" are the ones in the transitive closure of "Functional dependencies" (ie the only FDs are the ones that must be there when those ones are) then a minimal cover is
{user ID} -> {student ID, lecturer ID, guest ID, course ID, assignment ID, quiz ID, file upload, date of registration, date of latest logon, login account, password, first name, last name, e-mail, birthdate}
and the only candidate key is
{user ID}
and there are no non-prime column partial dependencies on a candidate key.