how do I draw a ERD with cardinality? I am still in school and I am not sure how to go about it. I just need a sample idea Thanks
Depends on the notation you're using. I find that putting something like "0..*" or "m" or "1" at one end of the relationship link, near the table it applies to, to denote "zero or more" or "m" or "exactly 1 required" communicates my intent pretty well.
Generally I like to use MS Visio(if you're a student you should be able to get it for free at Dreamspark.
Be sure to think about INSTANCE in ERD's instead of classes (I.E. an entity would be called Student, NOT Students).
Avoid many-to-many relationships as they don't make logical sense. instead use associative entities (See here).
Start with only displaying maximum cardinality Student has many Grade and grades belong to one student:
(student)|---<(Grade)
Then get into Minimum cardinality Students don't have to have grades so Students have 0-Many Grades, but a grade MUST belong to a student so a Grade has 1 and only 1 Student
(student)||---0<(Grade)
To read the above example you begin at the first entity, and identify the relationship. The entity is (student) and the relationship connects it to (Grade). Look at the cardinality markings on the OPPOSITE side that you started from. Since we started at (Student) we're looking at 0<. Closest to grade is the MAXIMUM CARDINALITY, or the most (Grade)'s that a student can have. the < means a (Student) can have many (Grade)'s. The 0 is the Minimum CARDINALITY, and it tells us whether or not the relationship is required. in this case it's a 0 and not a | so it's not required
Related
I need to normalize this database. This is for an application that will be allowing users to sign up for gaming tournaments that will be hosted at actual locations. When you search for a tournament the user can either register for the tournament, sponsor the event, or view the tournament. There will be multiple tournaments such as Fortnite, Apex, and what have you. The games will be on platforms like PS4 , PC, and Xbox one. Multiple players can be in a tournament, and they can be signed up for multiple tournaments at a time, same for viewers and sponsors. Each result should be stored such as wins and losses, and be put into the leaderboards. Please help me normalize this ERD diagram.
To normalize a database you have to make sure of the following rules:
1) Values in each column of a table are atomic.
I'm not sure what do you intend to keep in the wins and losses columns of your tables. But they have to be atomic. The number of wins is ok, but what are the wins is not.
2) No duplicities
I'm not seeing any obvious duplicity so I think this part is Ok.
3) No transitive dependency
In the Tournament Table there are both Teams and Gamer FK. If the gamer can only be in a Tournament if he is on a team, so you have a transitive dependency and should remove the GamerTag of the table. The same goes for the LeaderBoard and Results Table
There are other corrections, like in the Game tables theres an 'attribute name' column. In Team table the TournamentID is not set as FK, and GamerTag is not a FK because is not a PK in the gamer Table. User table has an 'attribute name' also. Among others.
Besides that, I'm not sure that this model will actually do what you want it to do. In general the names of your columns are not mnemonic so I cant be 100% sure of what they are. Like the what is the Leader Fk in Results table.
For a first model it's a good start. I recommend, before you continue to normalize it, revise it with care, write what are the purpose to each column.
Normalization is a nice thing to do with your tables but is not always the best way to store them. So I would also stop to think if it's really necessary to do it.
ERD from Wikipedia:
I'm confused to distinguish "has" and "contains" relationship in ERD, what's the difference between them?
With regards to the linked diagram from Wikipedia, both Has and Contains are one-to-many relationships (1..n) with total participation of Character in the relationship (double association line). Total participation means every Character must be related to an Account and a Region.
However, the Has relationship is marked as an identifying relationship (double-bordered diamond) and Character is marked as a weak entity set (double-bordered rectangle). This means that the identifying attributes of Character include the identifying attributes of Account. Character has a weak key CharName, which must be combined with AcctName to fully identify a Character. In other words, the primary key of the Character table will be composite: AcctName, CharName.
Note that these comments apply to the example ERD, not to ERD in general. Has and Contains aren't types of relationships - in general, a relationship can be called anything and have any combination of the features available in ER theory.
Also, see my answer to Is optionality (mandatory, optional) and participation (total, partial) are same?
There are 3 entities:
vehicle_model
vehicle
extra_options (such as open top, leather seats, etc..)
Vehicle model can have a subset of the extra options.
Vehicle can have a subset of it's model extras.
I've been trying hours to figure out how to represent this as er diagram, but without success. I Thought about ternary relationship ,and although I don't understand it completely I think this isn't the way.
I thought about creating another 2 entities, model_ext & vehicle_ext ,so that vehicle_ext would be connected to model_ext but this isn't a good design.
This is my first er diagram design. I'm really lost (read er-diagram chapter in "Silberschatz, Database System Concepts" three times already) so any idea would be appreciated.
did you try adding a new table say 'vehicle_vehicle_model_extra_options_map'? (you can name this table to any thing short, but for better explanation i use __map as a standard way for defining the map tables.)
note those two null able foreign key columns in this table.
Basically, vehicle has one to many relation to extra_options, and vehicle_model has one to many relation to extra_options table, therefore the new table was added.
updated:
Let us say I've two Leagues L1 and L2. Each league can have multiple rounds like Playoffs, Quarterfinals, Semifinals and Finals. Moreover, I also need to represent the happens_after fact like Quarterfinals happens after Playoffs, Semifinals happens after the Quarterfinals and Finals happens after the Semifinals.
Questions
Should my graph have one node for each of these rounds and each League should link to these rounds? This way we are just creating new relationships (e.g. both L1 and L2 will have a relationship to Playoffs) but there is only one Playoff node. However, this limits the happens_after relationship because some leagues can have more rounds (for e.g. Round 2 can come before Quarterfinals). Is there a better way to represent this?
Use-cases
Need to be able to find all the rounds of a given league.
Need to be able to find the order of all the rounds of a given league and the dates each of these happened.
EDIT
In general everything that has an identify on its own should become a node. Relationships tie the "things" together.
Not sure if I fully understand your domain. L1, L2 and each round would be nodes. The relationship league -> round indicates that a given league takes part in the round.
The temporal order within the rounds can be modeled by having BEFORE and/or AFTER relationships among them. This way you build a linked (or a double linked) list of rounds.
Another way to express temporal order would be to store a indexed timestamp property for the round. If you're just interested in before or after and not on absolute time, the first approach (linked list) seems to fit better.
I'm getting to grips with using 'crows-foot' notation to design Sqlite databases using Navicat. In a book chapter designed to get users up and running with this software I have come across the following example, consisting of an ER diagram and some explanatory text:
There is a many-to-one relationship between the category table and the task table. In our case, a task can have one category associated with it, but a category can have many tasks under it. As such, a task can be assigned to one user, but a user can have many tasks.
I was surprised to read this because the notation seems to be at odds with the description. My way of reading these diagrams (arrived at by examining various freely available examples on the internet) is to start with the table (say Task) then look at the notation that is 'attached' to the related table (in this case 'one or more') and construct the relationship as follows: Task belongs to 'one or more' Categories. Such a relationship is possible of course, but it seems inconsistent with the verbal description of the desired relationship, namely: 'a task can have one category associated with it'. Am I misunderstanding crow's-foot notation?
In ERD (whether using Crow's foot or Chen notation) the "many" side has always the foreign key, The Task table has the foreign key Category_id and therefore is on the "many" side while Category has the related primary key named ID and therefore is on the "one" side. So, you're right in your interpretation actually.