I have designed a simple database ER Diagram, now I've to normalize it. I've a ternary operation in my ER Diagram they are:
Staff(StaffId,StaffName);
Student(StudentId,StudentName);
Opportunity(OppId{PK})
The relationship_name of these three is responsible and cardinality is Many-to-Many.
My question is what do first in normalizing , is it many- to -many relationship or the ternary relationship ?
I'm learning about creating databases in MySQL and one of the theoretical parts is developing ER diagram.
Do I really need it when making my own project? And if I want to create one, do I create it after normalization of relations?
1). You're not required to do it. But it can definitely help to keep a clear overview over your scheme.
2). I'd just start by making an ER diagram and updating it after, or during, normalization. You could use tools like MySql Workbench to easily make and manage ER diagrams
Normalization technique must be the part of database refinement which has to be carried out before Entity Relationship Diagram.
As in ERD technique, we find out Primary Key and Foreign Key, using the same relationship amongst the entities.
Can anyone point to the right direction for reference about converting ER digram to relational schema using relational predicate? I looked online and found some. But they are so abstract and do no include any examples at all.
You need mapping rule, maybe this can help you.
Rules: https://www.tutorialspoint.com/dbms/er_model_to_relational_model.htm
I have the above tables in a database I'm designing right now, in MySQL. The primary purpose of the database is to create Bill Of Materials for a database and enforce revision control on these Bill Of Materials.
The Parts table follows Single Table Inheritance and has 3 different types of parts: Connectors, Terminals, Seals.
Brief Description Each Type
Connector: These are automotive grade connectors used in the manufacturing of automotive wiring harnesses.
Terminals: A connector has crimped wires inserted into it. A Terminal is crimped onto a wire in order to create a solder-less joint. These terminals then mate with their counterparts when the connecter is mated with it's counterpart in a vehicle.
Seals: These are special type of seals that are inserted onto the the wire in order to prevent water/dust getting through to the interconnection.
A connector can be used with multiple types of terminal and a terminal can also be used with multiple types of connectors.
The relationship between a connector and a seal is similar. A seal and terminal have no relationship.
What I'm aiming for:
If the user is browsing some part, I would like the view to show all it's related/associated parts. For instance, if Connector id 1 can be used with 5 different types of terminals, I would like all these terminals be shown in the view.
Similarly, when Terminal is being viewed, I would like all the different connectors that it can be used with shown as well.
Furthermore, a Connector can have substitute parts and I would like to relate that as well. This is a one-to-many relationship as a connector can have multiple substitutes.
And finally, a Connector can have multiple counter-parts and I would like these to be related as well.
I'm new to database design and I'm having trouble seeing the forest through the trees. Personally, I think I should ditch the Single Table idea and go with separate tables for Connectors, Seals and Terminals and draw up relationships between them.
That still answer how I can show substitutes and counter-part connectors.
If you are looking for an alternative to single table inheritance, look up class table inheritance. In your case, this would mean four tables in place of parts: Parts, Connectors, Seals, and Terminals. If each of the last three tables use shared primary key off of the parts table, you'll enforce the 1-to-1 nature of the "is-a" relationship, but not the mutually exclusive feature.
More to the point, you have not modelled the relationships between parts and other parts that you outlined in your verbal description. Those relationships may be inherent in the BOMS you create, but they aren't obvious here. If you model those relationships, will it make the database more functional? I don't know, offhand.
If you are having trouble seeing the forest for the trees, it may be that you are trying to design the solution without having analyzed the problem. I have found it handy to analyze the subject matter using the ER model. This breaks the subject matter down into entities, relationships, and attributes, but doesn't say anything about table design. Hint: your model is a relational model, not an ER model, even though you use ER diagramming conventions. Again, in my experience, once I have an ER model that describes the problem, it's easy (although tedious) to devise a relational model that designs the solution.
Is there any tool which take ER diagram as input and generate Object Relational Database Design in return? More specially is it possible with mysql workbench?
Thanks.
Power Designer (sse description) looks like it will do what you want. It's kinda pricey.