How would you improve the database design diagram you created for the package shipping information system requirements scenario (Unit Scenario) you submitted last week (Unit 08: Database Design)?
Reader Interactions
Comments
Leave a Reply
You must be logged in to post a comment.
Imran Jordan Kharabsheh says
After looking back on my entity relationship database design diagram from the previous assignment, I noticed that the design you had shown to us in class had shown significant differences to my own, which seemed unrefined in comparison. The first change I would do, and is much needed, would be to re-establish the relationships between entities in my diagram, as I am missing some key relationships including a direct relationship between customers and the orders themselves. I would also put in the effort to create more entities to tackle my issue of assigning too many non-key properties under certain entities, such as how I listed Vehicle ID under the Employee as opposed to creating a Vehicle entity and using it as a primary key. Another major change that I would make to my diagram would be to review and reallocate the properties of the customer database and its associated entities to ensure that I’m not overly-repeating properties. The final change that I would make to my assignment would be to merge the customers and businesses entities while still ensuring that the database and employees who check it can differentiate between the two.
Alexander Reichart-Anderson says
Upon reviewing the database design diagrams at last weeks class meeting, I have numerous improvements I would add to my diagram. The first section of improvements deals with the entities I selected. My entities were not as detailed and I left numerous ones out. I left out the following: van, diver, employee(s), client, address, and documentation. I would first list the entities and their attributes followed by assigning their relationships to other entities. In terms of relationships, there was room for improvement here too. When I originally created my diagram I had one relationship to and from each entity (aside from my main “order” entity). Moving forward, I would not be hesitant to create more relationships among all of the entities (as they applied). Finally, I would improve the overall visual appeal of my diagram. I would color code the different types/classes of entities to help the users understanding of my diagram.
Imran Jordan Kharabsheh says
Hello,
As I was glancing over your list of improvements you would make to your database design entity relationship diagram, I began to draw many parallels with the improvements I felt I needed to make as well. In a similar manner to your own diagram, I also felt that my entities and their attributes needed to be reviewed after seeing Professor Lanter’s example. I also really liked your suggestion of color-coding the entities based on either the significance to the overall database or the category of entity that it is.
Shuyue Ding says
I would add cross-reference tables into my ERD last week for many to many relationship tables.
I would eliminate duplicate attributes from different tables.
I would replace some solid line to dashed line when its a weak relationship and not ID dependent.
I would use composite primary keys.
Penghui Ai says
Hi Shuyue,
Even though I cannot see your diagram, I still can understand your basic idea of the changes you gonna made. What I wanna do is to make some cross-reference tables as well; however, one thing needs to consider is whether to add foreign keys and what foreign keys need to add when adding cross-reference tables.
Sarah Puffen says
I also have a bunch of repeating attributes, and I didn’t see a problem with it at first but now I understand how it can be counterproductive in database design. I’m glad you mentioned changing some solid lines to dashed, because I completely forgot to include that when reevaluating my diagram.
Yuchong Wang says
After taking a good view of other people’s work. I think I can improve my ERD by adding more entities. Many of the entities like drivers, product and shipment, I listed them as part of the attributes, but I think I could use them as entities. For example, I can use the driver as an entity and put the driver’s name, driver’s departing time, driver’s time to pick up the package as my attributes. I also gained a better knowledge of primary and secondary key and I should adjust some of my primary key and secondary key.
Yuan Liu says
I think we have similar problem in the diagram designing. There should be a specific detail to describe the information transfer between each entity. Otherwise, There should be more entities to relate precise information transaction.
Deepa Kuppuswamy says
Based on our discussion, my database design diagram needs the following improvements:
> Relationship between tables depending on one-to-one, one-to-many and many-to-many needs to be identified appropriately.
> Learnt the usage of cross-reference table
> In order to make my database design structurally correct and optimal, I need to make sure normalization rules and appropriate integrity rules are applied in my design.
Feng Gao says
Good improvements. Last week of the database design diagram can use one-to-many and many-to-many. Also, you said cross-reference table, and this is important. We need to make sure foreign key and private key.
Shuyue Ding says
Hi, Deepa;
I had made a similar mistake as you which I had duplicated attributes in different tables, and I believe it would cause problems like inconsistent if anyone tries to conduct and run it into MYSQL.
Alexander Reichart-Anderson says
Hello Deepa! Relationships are certainly an area where I feel that most of us could improve our ERD’s. For some reason I have issue with determining 1:M, 1:1, M:M, and so on. Cross reference table are something I’ve been forgetting since MIS 2101 (I might need to tattoo those terms on my arm). And the normalization technique is quite new, so I can understand why we need to add that!
Feng Gao says
According to last class meeting, I review my data design diagram. I need to add more entities and improve my diagram. Detail information is as follows:
The package table is used to save package information, including the name and type of the package.
The driver table is used to save driver information, including name, contact information and other information.
The address table is used to store address information, including information such as name, usage status, and postal number.
The payment form is used to save payment information, including date, cost, type, remarks and other information.
The account table is used to save billing information, including information such as the most recent payment.
The customer table is used to store customer information, including name, contact information and other information.
The delivery table is used to save shipping information, including address, date, signature, name, and more.
The pickup table is used to save sorting information, including information such as address and date.
The modify_log table is used to save changes, including operator, operational behavior, date, and more.
The order table is used to save order information, including foreign keys for all the above tables, as well as other order status, fees and other information.
Zhu Li says
After reviewing the database design in the class, I to improve my diagram. First, I would change some solid line to dashed when there is no primary key. Then I would reset the relationship of primary key and secondary key. Second, I will create more tables and entities, primary relationships such the orders and customers, and some attributes. Thirdly, I should follow normalization rules and understand the characteristics of every construct, such as data entities, relationship, and their associated attributes. Such as it is the difference the entity types and instances.
Yuqing Tang says
Hi Zhu, thanks for pointing out the first point, which I literally forgot. And I have the same feeling with you, which is reconsidering the entities I chose. When I drew the diagram last week, I chose the entities only from what mentioned in the instruction without thinking about what are missing from the whole process.
Deepa Kuppuswamy says
Zhu, I liked your third point. Even I had completely missed the normaliation rules when I initially constructed my database design. When i tried to reconstruct my design after the class, I was able to clearly see how the normalization helped in reducing the redundancy and the duplication of data. It also helps in maintaining data integrity and scalability.
Sarah Puffen says
While learning about data normalization in class, I loosely associated this process with meiosis in cell division – in this example, one table being divided into four different but correlated tables. In order to improve on my database design, I would utilize data normalization to simplify my tables so that they only contain attributes related to the main entity, while also adding more relationships between appropriate tables. I would similarly indicate when any type of PII was involved within a table, such as a credit card or address, to guarantee that this type of information has a security control.
Zhu Li says
Hi Sarah,
Our situation is similar. I also need to create some tables and reset relationships between appropriate tables. Such as, in some cases, represent a relationship by making the primary key of one relation a foreign key of another relation. in other cases, create a separate relation to represent a relationship.
Penghui Ai says
After taking the class of last week, I realized that I can improve my database design diagram I created for the package shipping information system requirements scenario. The main thing I will do to improve my database design diagram is to separate the delivery order into many different tables.
•I will first change the name of the table called “delivery order” into “order”
•For the attributes of “pickup location” and “date and time that he received the order,” I will make one new table called “order pick up info” to contains this 2 information, and I will add a foreign key called “order id” in this table. This table has a connection with the “order” table
•For the attributes of “order status,” “type of delivery,” “weight,” and “cost,” I will make a new table called “order delivery info” to contain them, and I will make a foreign key called “order id” in this table. This table has a relationship with the “order” table.
Ryu Takatsuki says
Hi Penghui, I like your ideas. I think the order pick up info is a good table since it will make it clear to understand. Also, the order delivery info will reflect the package itself. Overall, I think it is good to separate these two tables and reconnecting them.
Yuqing Tang says
First, I would reconsider the entities I chose. Last week, I only chose entities and their attributes which are mentioned in the scenarios without having additions. After the lecture, I realized, instead of only listing what mentioned in the requirement scenarios, I also need to think about what entities and attributes are needed and had functions in the whole process. Also redrawing the entities, the relationship among them would change too.
The second improvement is that, I would separate the attributes. I copied a few attributes (data and time, name and address) from the requirement and regarded them as a single attribute, but after the lecture, I learned that the results cannot be reached if putting more than one in the same attribute.
In addition, I think I should also rethink about the foreign key and also point them out in my diagram.
Haixin Sun says
I would adjust the entities.
I would adjust the attributes.
I would point out the foreign keys.
I would restructure the tables to make them clearer.
Ryu Takatsuki says
There are several things that I want to improve my database design diagram. I think could make the invoice more clear by separating the monthly payment for the business customer since I could cause confusion for the system. Also, I would add a tracking entity. I think it could make the whole database more smooth because the customers, receivers and delivers could all locate the package and time for delivery. Moreover, I would delete the description between each entity and rethink about the one to many and one to one relationship between each entity.
Raisa Ahmed says
There are a few ways I would improve the database design diagram I created for the package shipping information system.
1) Examine if the relationships made between the entities were correct and possibly add more entities
2) Modify the overall layout of the diagram to one that is more easily understandable by placing the entities in an appropriate order and not just anywhere
3) Add primary and foreign keys to the diagram
Deepa Kuppuswamy says
After going through your points, I just realized that even I had missed out to add primary key and foreign key references in my diagram. Though I added the primary key and foreign key in a seperate table, i think it would make more sense when we add it in the database design diagram.
Yuan Liu says
After the reading, there are several point improved in the database diagram.
(1) There should be a specific entity description and precise information transfer detail between entities in the information transaction.
(2) Organizing the diagram to show a clear information transfer logic to help users easily understand.
(3) Creating a description to explain the relationship between each entity.
Yuchong Wang says
Hi Yuan,
I think we have similar findings after our class. I found myself needing to adjust my entities and attributes allocation because I see so many entities could be placed while my diagram only placed 6. And my diagram design is also not aesthetically looking good so I also would like to change my diagram’s interface a little bit.
Panayiotis Laskaridis says
I would include more entities for employees.
I would add an entity for warehouse employees as well.
Given the scenario, I would add more relationships between entities.
I forgot to list the primary keys for each entity.
I didn’t describe the relationships between entities
I would order the process numerically
Raisa Ahmed says
Good improvements, fam. I actually want to make similar improvements. As far as the whole diagram goes, I would put some order into where I place the entities. Also, I would add more entities and add primary keys to those… i do not think I did that the first time around.
Mei X Wang says
I would reread the use case again and better identify my entities and the relationships they have. I would list the primary keys for each entity and I would organize the designs better. I didn’t understand the different relationships so I should’ve fully understood how to document each relationship.
Xinye Yang says
Hi Mei
I have the same problem, I need to study the use case as well, Better understanding of the foundational technique and relationships they have will help us on building database design diagram. Normalization technique is important, we should focus on it, It is a database design technique which organizes tables in a manner that reduces redundancy and dependency of data.
Xinye Yang says
the database design diagram I made last week was messed up.
I would start over by reviewing the basic foundational technique “Normalization”
I was confused about foreign key, and I was unable to differentiate primary key and foreign key, Foreign key ensures rows in one table have corresponding rows in another. Unlike the Primary key, they do not have to be unique. Most often they aren’t. Foreign keys can be null even though primary keys can not
I would study how to identify The first normal form rules and second normal form rules