While pretty good, this video has a number of simplifications that might mislead. ERDs can be used to capture design intent at a more conceptual level and/or a more "physical" level (implementation with actual database tables etc). The video says that a many-to-many relationship is not possible. This is incorrect. It is completely possible. To capture a many-to-many relationship between EntityA andEntityB, just draw a relationship between them with crows foot on both ends, and that expresses the intent correctly. However, most databases don't have a way to directly implement that. Instead you need an intermediate join table, with a one-to-many relationship from TableA to the join table, and similar for TableB. So at 14:34, actually the correct answer is Diagram A, because at least it is correct, though requires expansion to actually implement. Meanwhile, Diagram B is incorrect because the relationships to the intermediate ASSIGNMENT table are incorrect. (Also, in the description, the use of "however" is misleading. Just use "and".)
entity= table, row=instance, column=attribute. if i have an entity and i want it to have an attribute of which it could have 0 or 1 or many, then its time to make that attribute its own table. i have a student entity and i want to give it a phone number as an attribute but then i realize that a student can have 0 or 1 or many phone numbers, so that tells me phonenumber should be its own table that i would be called phone.
No doubt it is a very well done lecture. I just want to correct for future learners that @10:09 this is a SuperType/SubType Scenario and so there is a mistake in it. It is an IS-A relation and the min/max cardinality on both sides is one-and-only-one. As you can see when the subtypes (Undergraduate/Graduate) using the primary key from Student table and doesn't have their own primary, it actually says that "Undergraduate/Graduate IS-A Student". And Primary Keys are Unique, so once a subtype instance relates to a StudentID of an instance of a supertype then there is no possibility for any other subtype instance to relate to that same StudentID. At @11:34, this diagram is corrected for Hourly_Employee and Salary_Employee. But again a mistake on Assignment table, it should be one-to-many from both sides.
There is an error with cardinalty between project and assignment it must be inversed that one project could have 0 or many employees in it 0 employees means that the project could be a new project comme to life or in the actual moment nobody care about this project :( so from project is || and from assignment is 0<- so it look || 0<- from emp to assignment
The best tutorial.
While pretty good, this video has a number of simplifications that might mislead. ERDs can be used to capture design intent at a more conceptual level and/or a more "physical" level (implementation with actual database tables etc). The video says that a many-to-many relationship is not possible. This is incorrect. It is completely possible. To capture a many-to-many relationship between EntityA andEntityB, just draw a relationship between them with crows foot on both ends, and that expresses the intent correctly. However, most databases don't have a way to directly implement that. Instead you need an intermediate join table, with a one-to-many relationship from TableA to the join table, and similar for TableB. So at 14:34, actually the correct answer is Diagram A, because at least it is correct, though requires expansion to actually implement. Meanwhile, Diagram B is incorrect because the relationships to the intermediate ASSIGNMENT table are incorrect. (Also, in the description, the use of "however" is misleading. Just use "and".)
where are u, please do more vids
I have a database exam tomorrow and i cant believe i am being helped by a 11 year old video
Sooo good
Wow they dont teach like this anymore... Time has changed and this video made it so easy to understand
very easy to understand video, thank you
you teach so well....i like the way you have the conversation with the student
entity= table, row=instance, column=attribute. if i have an entity and i want it to have an attribute of which it could have 0 or 1 or many, then its time to make that attribute its own table. i have a student entity and i want to give it a phone number as an attribute but then i realize that a student can have 0 or 1 or many phone numbers, so that tells me phonenumber should be its own table that i would be called phone.
entity= table, row=instance, column=attribute. and they just couldn't have said it like that in class or as a matter of fact anywhere else.
The last question seemed to be solved wrongly. employees and projects. Anybody find the same issue?
very informative, Thanks Gina! also the music for the examples is lo key kind of hard
Idk I watched many videos, but this 11 year old video had no match to today's yt ERD tutorial
Very enlighteing video. Well done!
11 years ago
Thank you, this video has cleared my doubts about ERD.
Thanks!
14:44 why is the foot assignment-one to many-projects?
Thanks this was very clear. I was able to follow along.
Epic, thank you so much.
YOU GUYS ARE AMAZING!!!!!!!
very good video (:
amazing
I feel this is the most clear and effective RUclips video on database ER diagram out there.And I cant believe that this was made 10 years ago
tells you how low quality the youtube courses became
this video aged very good!
The incorrect sound is giving me ptsd.
Love this, covers everything ❤
importance of erd in capturing data
No doubt it is a very well done lecture. I just want to correct for future learners that @10:09 this is a SuperType/SubType Scenario and so there is a mistake in it. It is an IS-A relation and the min/max cardinality on both sides is one-and-only-one. As you can see when the subtypes (Undergraduate/Graduate) using the primary key from Student table and doesn't have their own primary, it actually says that "Undergraduate/Graduate IS-A Student". And Primary Keys are Unique, so once a subtype instance relates to a StudentID of an instance of a supertype then there is no possibility for any other subtype instance to relate to that same StudentID. At @11:34, this diagram is corrected for Hourly_Employee and Salary_Employee. But again a mistake on Assignment table, it should be one-to-many from both sides.
Thanks a lot, explanation really clear
amazing
when we do the student, graduate and undergratue tables. studentid is an attribute for all of them rifht? kindof like inheritance?
10yrs old video solve my problem in RDBMS haha thank you so much
Amazing, you should make more videos like this...
Wow great lecture
There is an error with cardinalty between project and assignment it must be inversed that one project could have 0 or many employees in it 0 employees means that the project could be a new project comme to life or in the actual moment nobody care about this project :( so from project is || and from assignment is 0<- so it look || 0<- from emp to assignment
This was so helpful!! Thank you
Thank you for this! Super cool video! A+++
Extraordinary. Thanks.
still helpful..even after 9 fukin years👏🏿
yupppp, was thinking the same
What did you learn about the terms Entity, Attribute, Primary Key, Relationship, Cardinality, Crow’s Foot Notation, and Business Rules?
This was helpful 9 years later! Thanks. I hope all is well.
This is such a great lesson! Why can't they teach like this at my university, which I had to pay so much $$ for.....
Amazing lecture and Background music :)
Very amazing tutorial! Thank you so much.
Perfect. Listened to it 5 times. I’m ready to not fail
Legendary video.
what are you talking about?It's amazing!!!I like this video!!!!!!!!!!!!!!!!(类里类里鼓的）
Thank you well compressed info Maam
This was neat, college brought me here.