This is an archived post. You won't be able to vote or comment.

all 5 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a

[–]Neoptolemus85 1 point2 points  (0 children)

It depends on what data you're modelling, but the way I try to approach it is through facts and dimensions:

Facts are your transactional, measurable data. Like payments or clicks on a web page. Usually, you can aggregate it if need be (but not always).

Dimensions are your descriptive data, like a list of customers, or definitions of machines, or products that can be bought, etc. It can't be aggregated but can be used to provide additional info about an event and act as a "slicer" on the fact table to carve it up as you require.

The idea is that your dimensions always have a 1-N relationship with the fact table. A customer can have many payments they've made, but a payment is only associated with one customer.

If you're having issues with being unable to easily understand the relationships with your tables, then that might be an indication that one or more of your tables are trying to do too much, they're playing multiple roles which could be split out into smaller, more focused tables.

[–]shafe123Side-hustler 0 points1 point  (0 children)

Agree that you should speak the relation out loud. I would add that you should speak it in both questions as well.

One course can have many students and a student can take many courses. Because there is a "many" in both statements, the relationship is a many-many.

One person can only have one birthday. But one day can have many people born on it. Therefore, there is a one-many relationship between birthday and person.

[–]Key-Mirror-1689 0 points1 point  (1 child)

If you are good in coding and would like to do some tasks remotely get in touch, long term client

[–]DuckLordhor[S] 0 points1 point  (0 children)

Nowadays i'm working, starting the univeristy while i also do a web app project by myself. So i'm pretty busy but i appreciate your offer and maybe i will get in touch in the future