Be sure to SUBSCRIBE for regular BA training and tips! Also, For Business Analysis TEMPLATES that will help facilitate the requirements analysis and documentation process, check out our BA Templates and Elicitation Questions Package here: the-business-analysis-doctor-self-paced-learning.thinkific.com/courses/business-analysis-template-package
This tutorial was more helpful, straightforward, and informative than the first 5 chapters of my textbook that was assigned for Data Management course. Thank you for this incredibly helpful material.
WOW! I'm am so glad I was able to add value to your learning experience. This is so encouraging to keep creating this type of content! You might also find my tutorials on Data Flow Diagrams and Sequence Diagrams useful as well. All the best on your studies!
ERD: Turning database chaos into crystal-clear logic, one crow's foot at a time! Finally, a tutorial where relationships make more sense than my dating life! Thanks!
Thank you so much for that awesome review! I'm do glad I could present the information in a way that is easy to consume! I hope the information serves you well! Also, check out my videos on the data flow diagram and sequence diagram. You might find those helpful as well. Cheers!
This was such a clear and informative discussion of ERDs! You made everything so easy to understand, especially with the example at the end. I feel confident enough to start creating my own ERD now. Thanks for making these concepts so understandable, Dr. White!
Such a great and understandable description of ERDs! The division of mental, logical, and physical levels greatly aided my comprehension of how these representations develop. The library example was dead on. It made the concepts really approachable. Are there any ideas for dealing with contradictory business regulations while generating these diagrams? Thank you again for the amazing content!
What a thought provoking question? To address contradictory business rules while generating entity-relationship diagrams (ERDs), start by identifying and documenting each conflicting rule in detail. Analyze the rules to determine their source, scope, and intended purpose. Engage stakeholders to clarify ambiguities and understand the rationale behind each rule. Use prioritization techniques, such as MoSCoW or decision matrices, to align rules with business goals and identify which take precedence. Where possible, restructure rules to harmonize them or create conditional logic within the data model. Iteratively validate the updated rules and ERD with stakeholders to ensure alignment and avoid further conflicts. I hope that points you in the right direction?
In the last slide, the Book to Renewal relationship - I understand the premise but there is no Book ID in the Renewal table or a Renewal ID in the Book table... is this correct? How can a relationship be established here if there is no connection in relation?
Good Observation. Remember, when you are referencing a primary key in a table, you are pulling in all of the attributes that fall under that primary key. So by referencing the Checkout ID in the renewal table, that will pull in the Book ID (foreign key) from the checkout table. I hope that helps!
Thank you and you're welcome. A common mistake is overcomplicating the diagram by adding too much detail that can make the ERD difficult to read and understand. It's important to focus on the key elements needed to convey the relationships and structure of the data.
You are very welcome! Good observation. In this example, I didn't outline a business rule or requirement that would require me to display the relationship. Now, because I used the Book ID, which is Book's primary key as a "foreign key" in the Checkout entity, I technically should have included relationship lines to show their relationship. I hope that helps!
Nice overview of the bad old ERD - two things. Firstly, the ERD approach scares people - so many weird words - entity, cardinality, domains, nouns, primary key, foreign key. It's simply a way of describing a system so that a coder can use it to construct a Database. Why are we still doing this? BAs DO develop an understanding of the "System Model" (Types of objects / entities and their associations to other objects in the System) e.g. "Book" -> [author] -> "Contact" - a very simple vision of a system. That's all that is needed! Software can take it from there. Secondly, by dropping the ERD and using a system model approach, it is a much easier and better way to comprehend the System at the correct level of granularity for the process being developed. Of course, as you state, the ERD is really necessary for the coder. But imagine that once you have built your system model you can build your complete system WITHOUT using a software coder. That's what NoCode is all about. Let's move away from software design methods for the last millennium!
That's an interesting perspective. While I do love NoCode, unfortunately, not every organization has picked up this trend. So, in order for a BA or DA to be truly effective and versatile in any organization, they need to be adept in various methods of modeling systems. There's rarely a one size fits all approach. 😀
The thing about Product Owners is that they trust us, the BA's. We talk "human". we are part of the translation from Product owner to coder. No Code suits the BA down to the ground. You should give it a go. Means we become the developer, not just the conduit, opens a whole new chapter in software development, innovation, business security and on-going management. @The Business Analysis Doctor, LLC
I've actually been on a few no code projects in the past that involved building out workflows. I must admit it was liberating. But at the same time, being that close to the code takes away from the time I get to spend doing more strategic work. Which is an area I strive in. But I definitely think no code environments are great for those who prefer to be more hands on with the code while also having more autonomy.
i want help with an exercise that i have in the databas!Describe the type of relationship between STORE and ZONE reles ERD that reflect the relationship between the STORE and ZONE Describe the types of relationships between the WORKER and the SHOP.(each shop employs many workers,one of them manges the shop) create the ERD that reflect the relationship between STORE,ZONE and WORKER Create the rational diagram
Hi, Lude! I'd love to help you with your exercise! The best forum for this would be a coaching session. you can book a session via the calendar below and we can discuss the details further: thebadoc.com/services/ola/services/one-on-one-coaching-session Looking forward to working with you.
My system basically allows lecturers to upload notes and allows students to view, as well submit quizzes. Lecturers can then view the submission and upload assessment for students to view. My entities are quite unclear to me. I've got Student and Admin as my entities only, would there be any other?
Hi, Samuel! When you outline the requirements and processes that exist within the system or domain, you need to identity and extract any "noun" within those processes. Any noun that the organization wants to track and is required for the process to be completed is what you need to include in the ERD. So based on the bit of information provided the entities would likely be lecturers, lecture/lesson, student, notes, and admin if they are different from the lecturer. I hope that helps.
Good question! It's not necessary to show the relationship between the foreign key attribute and the original entity, but it can be beneficial for understanding the structure of your database, especially in complex databases. Especially at the physical level.
Thanks for watching! The ERD in the example is using crow's foot notation. It's also discussed in the notation section of the lesson. I hope that helps!
this was so hard to understand, I've been studying database for a few months now and found erd confusing so went to watch some video. This one just used such a hard way of explaining stuff and the concepts and everythign just made it so hard to focus and udnerstand.
Thanks for the feedback. I'll take it into consideration though it's counter to the typical response. Just curious if you can provide an example of one of the areas you found hard to follow?
This ERD tutorial was quite clear and detailed! I like how you broke down each section, particularly the explanations of primary keys, foreign keys, and relationships. Using the library book circulation example made everything clear. It's such a familiar scenario. I also found your description of conceptual, logical, and physical models really useful, particularly in bridging the gap between business and technical teams. Quick question, how do you decide which level of abstraction to utilize (conceptual, logical, or physical) and when to switch between them in a project? Looking forward for your thoughts. Thanks!
The choice of abstraction level in ERD creation depends on the project’s stage and the level of detail needed for the team’s objectives at that moment. A conceptual ERD is used at the early stage of a project, especially during initial requirements gathering and stakeholder discussions, where the focus is on understanding the core data entities and general relationships. Move to a more detailed model once stakeholders agree on what the main entities and their relationships are. This model often serves as the starting point for the logical ERD.
![Data Flow Diagram EXAMPLE [How to Create Data Flow Diagrams]](http://i.ytimg.com/vi/ab1DZ6o7QBs/mqdefault.jpg)
Be sure to SUBSCRIBE for regular BA training and tips!
Also, For Business Analysis TEMPLATES that will help facilitate the requirements analysis and documentation process, check out our BA Templates and Elicitation Questions Package here: the-business-analysis-doctor-self-paced-learning.thinkific.com/courses/business-analysis-template-package
This tutorial was more helpful, straightforward, and informative than the first 5 chapters of my textbook that was assigned for Data Management course. Thank you for this incredibly helpful material.
WOW! I'm am so glad I was able to add value to your learning experience. This is so encouraging to keep creating this type of content! You might also find my tutorials on Data Flow Diagrams and Sequence Diagrams useful as well. All the best on your studies!
ERD: Turning database chaos into crystal-clear logic, one crow's foot at a time! Finally, a tutorial where relationships make more sense than my dating life! Thanks!
I need this kind of tutorial in the database, easy to understand and very comprehensive I'm leaving 10/10, thank you
Thank you so much for that awesome review! I'm do glad I could present the information in a way that is easy to consume! I hope the information serves you well! Also, check out my videos on the data flow diagram and sequence diagram. You might find those helpful as well. Cheers!
You explained this so well! So many people have tried to train me on this and some of the concepts never made sense until now. Thank you so much.
You are most welcome! Glad I was able to give you a new outlook on the technique.
This was great! Thanks for sharing the tip about the noun technique. I've always found identifying which entities to include to be a challenge.
Excellent! Happy to provide the insight! I hope it makes your next ERD more effective!
Yep. Determining the entities was stuff for me too. Now I know how 😃.
This video is tooo good and underrated.
Thank you so much for that feedback and for watching! Glad you enjoyed the video.
This was such a clear and informative discussion of ERDs! You made everything so easy to understand, especially with the example at the end. I feel confident enough to start creating my own ERD now. Thanks for making these concepts so understandable, Dr. White!
Excellent! I'm so had to hear that you are now confident enough to attempt designing an ERD. Let me know how it goes.
your explaination is clear as cristal, much appreciated.
Excellent! I'm glad the content resonated with you. I hope this info on the entity relationship diagram serves you well.
Good presentation and effective explanation. Thanks ! Asst. due.
You are very welcome! I'm glad I was able to present the information in a way that resonated with you.
Man this is a great explanation, thanks a lot for your content
Glad to be of service!
The best I've watched 🎉
I really appreciate your kind feedback! It means a lot to know that my content resonates with viewers like you! I hope it serves you well.
This video is amazing!
Thank you so much for that feedback! I hope you gained a lot from the video.
Thank you for this very useful video!
You're very welcome! Glad you found the information useful.
Man that great explanation, thanks a lot for your content
You are very welcome! I'm glad you are finding the information valuable. Cheers!
This is a great explanation!! thank you!
You're very welcome! Glad to share the info. Also, be sure to check out the other tutorials like this as well! Cheers!
Such a great and understandable description of ERDs! The division of mental, logical, and physical levels greatly aided my comprehension of how these representations develop. The library example was dead on. It made the concepts really approachable. Are there any ideas for dealing with contradictory business regulations while generating these diagrams? Thank you again for the amazing content!
What a thought provoking question? To address contradictory business rules while generating entity-relationship diagrams (ERDs), start by identifying and documenting each conflicting rule in detail. Analyze the rules to determine their source, scope, and intended purpose. Engage stakeholders to clarify ambiguities and understand the rationale behind each rule. Use prioritization techniques, such as MoSCoW or decision matrices, to align rules with business goals and identify which take precedence. Where possible, restructure rules to harmonize them or create conditional logic within the data model. Iteratively validate the updated rules and ERD with stakeholders to ensure alignment and avoid further conflicts. I hope that points you in the right direction?
thank you for this clear explanation.
My pleasure! I'm glad I was able to clarify the concept for you.
Best tutorial
Thank you so much for those kind words. I'm glad you enjoyed the content!
In the last slide, the Book to Renewal relationship - I understand the premise but there is no Book ID in the Renewal table or a Renewal ID in the Book table... is this correct? How can a relationship be established here if there is no connection in relation?
Good Observation. Remember, when you are referencing a primary key in a table, you are pulling in all of the attributes that fall under that primary key. So by referencing the Checkout ID in the renewal table, that will pull in the Book ID (foreign key) from the checkout table. I hope that helps!
This tutorial does a great job of explaining ERD fundamentals! Good work. Btw, what are some common mistakes to avoid when creating an ERD? Thanks!
Thank you and you're welcome. A common mistake is overcomplicating the diagram by adding too much detail that can make the ERD difficult to read and understand. It's important to focus on the key elements needed to convey the relationships and structure of the data.
@@thebadoc Thanks for answering!
Thanks for the great explanation! I have a question - why didn't you add relatinoship between BOOK and CHECKOUT entities?
You are very welcome! Good observation. In this example, I didn't outline a business rule or requirement that would require me to display the relationship. Now, because I used the Book ID, which is Book's primary key as a "foreign key" in the Checkout entity, I technically should have included relationship lines to show their relationship. I hope that helps!
great bro
Thanks for the feedback and for watching!
Well done and easy to understand.
Thanks for the feedback! Much appreciated!
Nice overview of the bad old ERD - two things. Firstly, the ERD approach scares people - so many weird words - entity, cardinality, domains, nouns, primary key, foreign key. It's simply a way of describing a system so that a coder can use it to construct a Database. Why are we still doing this? BAs DO develop an understanding of the "System Model" (Types of objects / entities and their associations to other objects in the System) e.g. "Book" -> [author] -> "Contact" - a very simple vision of a system. That's all that is needed! Software can take it from there. Secondly, by dropping the ERD and using a system model approach, it is a much easier and better way to comprehend the System at the correct level of granularity for the process being developed. Of course, as you state, the ERD is really necessary for the coder. But imagine that once you have built your system model you can build your complete system WITHOUT using a software coder. That's what NoCode is all about. Let's move away from software design methods for the last millennium!
That's an interesting perspective. While I do love NoCode, unfortunately, not every organization has picked up this trend. So, in order for a BA or DA to be truly effective and versatile in any organization, they need to be adept in various methods of modeling systems. There's rarely a one size fits all approach. 😀
The thing about Product Owners is that they trust us, the BA's. We talk "human". we are part of the translation from Product owner to coder. No Code suits the BA down to the ground. You should give it a go. Means we become the developer, not just the conduit, opens a whole new chapter in software development, innovation, business security and on-going management. @The Business Analysis Doctor, LLC
I've actually been on a few no code projects in the past that involved building out workflows. I must admit it was liberating. But at the same time, being that close to the code takes away from the time I get to spend doing more strategic work. Which is an area I strive in. But I definitely think no code environments are great for those who prefer to be more hands on with the code while also having more autonomy.
i want help with an exercise that i have in the databas!Describe the type of relationship between STORE and ZONE
reles ERD that reflect the relationship between the STORE and ZONE
Describe the types of relationships between the WORKER and the SHOP.(each shop employs many workers,one of them manges the shop)
create the ERD that reflect the relationship between STORE,ZONE and WORKER
Create the rational diagram
Hi, Lude! I'd love to help you with your exercise! The best forum for this would be a coaching session. you can book a session via the calendar below and we can discuss the details further: thebadoc.com/services/ola/services/one-on-one-coaching-session
Looking forward to working with you.
My system basically allows lecturers to upload notes and allows students to view, as well submit quizzes. Lecturers can then view the submission and upload assessment for students to view. My entities are quite unclear to me. I've got Student and Admin as my entities only, would there be any other?
Hi, Samuel! When you outline the requirements and processes that exist within the system or domain, you need to identity and extract any "noun" within those processes. Any noun that the organization wants to track and is required for the process to be completed is what you need to include in the ERD. So based on the bit of information provided the entities would likely be lecturers, lecture/lesson, student, notes, and admin if they are different from the lecturer. I hope that helps.
Thank you :) ❤
You are very welcome! Thank you so much for watching!
Should you link book with check out? Since youre pulling the book id as a fk? Doesnt it need a direct link?
Good question! It's not necessary to show the relationship between the foreign key attribute and the original entity, but it can be beneficial for understanding the structure of your database, especially in complex databases. Especially at the physical level.
could you please make some videos about writing user stories in agile with some examples
Hi Riza! You're in luck! Check out the following video on User Stories in Agile: ua-cam.com/video/q26147zlcMU/v-deo.html
Let me know if this helps!
@@thebadoc thank you so much
@@rizabhandari545 You are very welcome! I hope it helps!
Good work
Hi, Cindy! I appreciate the feedback. Thanks for watching!
I wasn't expecting that accent 😂😂😂
Ha! I've heard that before. Curious what type of accent you were expecting.
what about erd using crossfoot
Thanks for watching! The ERD in the example is using crow's foot notation. It's also discussed in the notation section of the lesson. I hope that helps!
i have prepare a erd for airline
Wow ...that sounds interesting! I hope the video provides some guidance to you. Let me know how it goes!
this was so hard to understand, I've been studying database for a few months now and found erd confusing so went to watch some video. This one just used such a hard way of explaining stuff and the concepts and everythign just made it so hard to focus and udnerstand.
Thanks for the feedback. I'll take it into consideration though it's counter to the typical response. Just curious if you can provide an example of one of the areas you found hard to follow?
What the hell is sensco?
Ha! Should be "sensical" 😁
2/5/2024
Thank you for stopping by and watching the content!
Martin Brenda White Sharon Hernandez Matthew
Thanks for watching!
Honestly bro, that haircut is doing you dirty. I suggest trying out a new hairstyle or do videos with a fresh cut. Anyways nice vid.
Ha! Thanks for the unsolicited advice. Glad it didn't distract you from understanding the content.
💀💀
calm down it looks like you're about to pop out of the screen when the video begins
Ha! I am... I'm popping out to grab your attention! Thanks for watching.
@@thebadoc nice one🤣🤣
This ERD tutorial was quite clear and detailed! I like how you broke down each section, particularly the explanations of primary keys, foreign keys, and relationships. Using the library book circulation example made everything clear. It's such a familiar scenario. I also found your description of conceptual, logical, and physical models really useful, particularly in bridging the gap between business and technical teams. Quick question, how do you decide which level of abstraction to utilize (conceptual, logical, or physical) and when to switch between them in a project? Looking forward for your thoughts. Thanks!
The choice of abstraction level in ERD creation depends on the project’s stage and the level of detail needed for the team’s objectives at that moment. A conceptual ERD is used at the early stage of a project, especially during initial requirements gathering and stakeholder discussions, where the focus is on understanding the core data entities and general relationships. Move to a more detailed model once stakeholders agree on what the main entities and their relationships are. This model often serves as the starting point for the logical ERD.
@@thebadoc Thanks for taking time to answer my question. Appreciate it!