While doing this, I started realizing that redundant entities (in this case Cars and Trucks) can be combined into a single entity to simplify the diagram. I started this WOD by translating each object description into its own entity then creating their respective relations with one another. Requirements: Create an ER diagram from a textual description of a Car Rental service. For future reference, the primary key for both Reservation and Loan would need to be either an ID or a composite of all fields for the entity. I also included shared keys in both the Reservation and Loan entities to allow the library staff to search these databases for information. I decided to not implement a Copy entity and instead used an ID field as the primary key for the Book entities this allows multiple copies of a book to be stored as Book entities. My second attempt I tried to create a more compact ER diagram since I found my first diagram to be a bit cluttered. Since I do not trust my instincts when designing these diagrams, I do find myself second guessing certain field inclusions. I also noticed myself thinking about keys for each entity which may have caused some of my fields to become bloated since things like reservations and loan have data from the Book and Borrower entities. I could add things like an id field for the book entities to alleviate this but that does not follow what was specified in the requirements of the book. My biggest mistake during my first attempt was leaving out the entity for a copy of a textbook which makes in impossible for the database to have multiple copies of a single textbooks. Of course, it does not mean much when you miss a key entity of the relation. Knowing that I needed to focus on the logic behind the relations made this attempt much more deliberate. Requirements: Design an ER Diagram based on a textual description of a library database. Overall, nothing too tough since the book spells out the components of this database. I did not specify primary keys and did not include shared keys which make some of the entities (looking at you StockItem) a bit bare. I decided to go with the design to reflect the possibility of StockItem’s being zero since a Warehouse can have no stock and a Product can run out of stock. One thing I takeaway from the initial attempt is that I need to take it easy and think about logic of the relations between entities.īy the time I attempted this WOD a second time, I had done each WOD’s in this set at least once so I was starting to get the hang of designing “better” ER diagrams. I also found myself remembering a few concepts from my database classes and trying to implement learned concepts into the diagram which results in diagrams that are either overly-complicated or under-represented. Things like determining if the cardinality should allow zeroes or not is the thing that kept me second guessing myself through my first attempt. However, I did find myself having some logical holes when creating the diagram itself. Since this is not the first time I have worked with ER diagrams, I found this WOD not too difficult since the description in the Play for Java book was detailed enough to give the cardinality of the relations between entities. Requirements: Design an ER Diagram for the Warehouse database described in Play for Java.ĮR Diagram for the Warehouse database described in Play for Java.
![er diagram tool lucid er diagram tool lucid](https://i.stack.imgur.com/4bPFp.png)
ER diagrams shown as examples are the “best” attempts. However, I will freely admit that I do not design “good” databases since it is something I remember struggling with in prior encounters.Ĭlicking on the times for each WOD will open up the ER diagram created for that attempt. This is not my first time dealing with ER diagrams so I am somewhat familiar with how they work. The relations can be “one-to-one”, “one-to-many” and “many-to-many”. Crow-feet notation describes cardinality of the relation between entities. These ER diagrams will be using the crow-feet notation for describing the relations between entities. They describe the relation between entities in a database. These set of workout of the days (WOD) will be used to develop various Entity-Relationship diagrams (ER Diagram using Lucid Charts.Īn ER Diagram is an important part of designing a database. However, before implementing such functions, it is important to understand how data should relate to one another. This module will focus on laying the foundations to develop web applications that support persistence which is an important function of any web application dealing with user data (e.g. The web applications that I have created thus far were not persistent since they were gone the instant the Play Framework instance was closed.
#ER DIAGRAM TOOL LUCID SOFTWARE#
Lucid Charts is a diagramming software used for this module to create ER diagrams.