i am sooo disgusted how KZbin doesn't promote your account , a concept which i have learned in more than a week and still not understand but with simples videos of less than 12 min. i understood everything. thank you sir for sharing your knowledge. i whish you can do more
@trygvemb Жыл бұрын
What program did you use to draw those tables in. It looked like a super helpfull tool to get an overview when working with databases
@DustinOrmond Жыл бұрын
It is my own custom built application which isn't publicly available yet.
@fouz12453 ай бұрын
Thanks a lot, as a beginner to this concept why is Customer ID not the Primary key?
@DustinOrmond2 ай бұрын
Because it is determined by order_id. It is a primary key of the relation CUSTOMER, but not in 1NF.
@deepeshkc2 жыл бұрын
Thanks a ton Prof!
@رند-س5ح2 жыл бұрын
Thank you so much
@krisztiantamasi14938 ай бұрын
Thank you so much!
@apollyon252 жыл бұрын
I don't understand why you would add captain_Id back into the shipment entity. Wouldnt that violate 3NF? Because ship_id determines captain_id. You could get that information by joining shipment with the ship relation and then ship with the captain relation.
@DustinOrmond2 жыл бұрын
Because we have previously identified it as a transitive functional dependency. With multiple transitive functional dependencies, each one needs to be satisfied to be able to correctly connect the foreign keys to the primary keys.
@apollyon252 жыл бұрын
@@DustinOrmond I'm still confused, so ship_id no longer determines captain_Id? Why is that still not a transitive dependency? What do you mean by satisfied? Separated into a different entity? Why isn't it correctly connected without including captain_id?
@apollyon252 жыл бұрын
@@DustinOrmond Thank you for taking the time to respond btw, and so quickly no less. I appreciate it!
@DustinOrmond2 жыл бұрын
@@apollyon25 ship_id would still determine captain_id. Have you watched this video on transitive functional dependencies where we discuss all the transitive dependencies covered here? kzbin.info/www/bejne/r2jdZ2WqjJ6AipI
@apollyon252 жыл бұрын
@@DustinOrmond Yes I did, that's exactly why I'm asking. Shipment_Id determines ship and captain id, while the ship_id determines the captain_Id. That's a transitive dependency unless I'm missing something.
@STFUZReadTY3 жыл бұрын
Thank you so much for this video, can i ask regarding the 3NF relational model is it ok if i split the description into another table with the price?
@DustinOrmond3 жыл бұрын
I don't really see the need to do that. The attributes of price, description, and finish are all associated with the product. In other words, these are characteristics that describe the product.
@tamysiby2 жыл бұрын
Thank you so much for this! By the way, can you tell us the diagram tool that you're using? Is it online?
@DustinOrmond2 жыл бұрын
It is my own custom made tool. It is not publicly available...yet.
@kaspergos2 жыл бұрын
@@DustinOrmond Will it be available soon? Looks like it is very usefull!
@DustinOrmond2 жыл бұрын
@@kaspergos I am not sure at this moment.
@邱晨-g5d2 жыл бұрын
hi i was wondering if the result at the end match the logic model? if im doing a logical model should i just add captain id into the shipment entity thnx
@DustinOrmond2 жыл бұрын
The way I have it at the end is what you should do. You should have captain_id in both SHIP and SHIPMENT referencing captain_id in CAPTAIN.
@henriktunedal8075 Жыл бұрын
I watched the video on transitive dependencies and read your other reply about this, but I still don't understand how the last step (adding back captain_id to SHIPMENT) makes sense. If shipment_id uniquely identifies a captain_id (because "shipment_id -> ..., ship_id, ship_name, captain_id, captain_name") then that's no longer true in the final normalized form: looking up shipment_id now leads to two different copies of captain_id with potentially inconsistent values, so a particular shipment_id could e.g. identify captain_id 1 directly and captain_id 2 through ship_id, meaning that shipment_id no longer uniquely identifies a captain_id. What am I missing here?
@DustinOrmond Жыл бұрын
We aren't adding it "back". It already existed there but because of the two transitive dependencies, it appears we removed it with one and should add it back to the other. However, this is to satisfy the rule of each transitive functional dependency separately. Yes, you could just join the three tables together, but we were just evaluating based on the transitive functional dependencies alone. Also, this allows us to get captain information without needing shipment information. Ultimately, this is just following the rules of transitive functional dependencies. You may argue that you wouldn't need this connection for the future and it might be fine to leave it out.
@henriktunedal8075 Жыл бұрын
@Dustin Ormond Thank you! I get it now: The video demonstrates the result of strictly normalizing to 3NF which results in the field being kept. Setting 3NF aside though, it does look like a kind of denormalization to keep two mutable storage locations for a single piece of data (captain_id) and thus creating a risk of inconsistencies (but perhaps also better performance because of simpler lookups, as you suggest). Perhaps the copy is removed in higher normalization forms?