is there any way in MySQL or tool that could help me to transform a ER model to Logical model?
The ER model was done in MySQL, so if there's a way to use the file extension in another software that would be wonderful.
MySQL Workbench's models aren't really ER models. They're physical models consisting of tables and foreign key constraints. The entity-relationship model distinguishes between entity relations and relationship relations, but these would both be represented as tables in MySQL Workbench. Relationships in ER don't map to foreign key constraints, rather FK constraints enforce the domains of roles in relationships.
Automated translation from a physical to a logical model isn't possible, since the physical model doesn't capture domains or functional and join dependencies. ER models fare slightly better - domains are represented and some dependencies, but ER can't represent all possible relationships and constraints.
Related
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.
I have a core Java Web application backed by the MySQL database. The total number of tables are quite few, may be 10 tables in total.
Now the plan is to move to the 'JCR' backend, esp. Jackrabbit.
Question:
1. How to design the JCR related nodes based on the tables in MySQL ?
2. The MySQL tables contains the Primary key, foreign keys, so how the JCR entities need to be designed so that the JCR entities knows their relationships between each other.
Pool your ideas.
JCR is hierarchical and for content. Mapping relational tables 1:1 isn't the best approach. You want to look at your content/data and remodel it with the hierarchy in mind. Imagine you would be storing it in a filesystem.
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.
I want to get myself wet with the concept of implementing key/value stores with relational database languages (like mysql and sql server).
However this is one of the times when Google isn't good enough.
Does anyone know of any good info / good links regarding the concept of implementing key/value stores with relational database languages?
Wiki for EAV http://en.wikipedia.org/wiki/Entity-attribute-value_model. SO answer with link to whitepaper called "Best Practices for Semantic Data Modeling for Performance and Scalability" EAV over SQL Server
The primary reason to do a key value schema implementation in relational is to have the flexibility of a small sub-schema with key value aspects and the main schema being relational or vice versa. This could give one extreme flexibility to address key value lookups for some portion of the application and others a traditional relational option without having to keep multiple databases.
In fact we have implemented such cases for some of our customers, where the customers are either a specific relational DB shop or for the same above mentioned reasons. You can always create a key value store in a relational database but not the other way.