I am having a huge project and the entity relationship diagram is looking pretty crowded. So I was thinking about to separate the big entity relationship diagram in two or maybe more diagrams.
But I can't find a proper way to do that and still have like an component diagram which I can connect the diagrams somehow ...
At this moment I am not even sure this is possible..
So if not is there at least a way to don´t show the bubble-attributes in your diagram?
Related
I've been learning Ruby on Rails for quite some time now and have built several toy applications. I've taken many classes/courses (i.e., Hartl, Code School, Udemy, etc.). Now I'm working on a pet project that is fairly complex - many models and relationships.
Here's my question: How do I go about thinking about a complex application in terms of models and relationships? It seems to me there should be some visual way to model all of this, but I haven't seen any discussion of such modeling in any of the classes I've taken. Sure, there's the very simple diagrams in the Rails Guides, but how do I extend this to something more complex? Or, am I making this too complicated? Do I just start coding models and relationships and see where it takes me? It seems this ad hoc approach could easily paint me into a corner where I'll have to start over from scratch if I paint myself into a corner, so to speak.
Are there tools or blog posts that can help me?
(Note: I've also posted this question at Reddit.Com/r/Rails at https://www.reddit.com/r/rails/comments/7c9zbf/how_to_think_about_rails_web_application/)
It sounds like what you're after is a schema designer. I'll link one at the bottom of this post. A schema designer will allow you to visualize all the relationships in your application, and see how one model connects to another. They're really helpful in writing complex DB queries. I've attached an example of a fairly simple design just to give you an idea what they do.You can also add all the columns a model has in the design, I just usually use it more for relationships.
http://ondras.zarovi.cz/sql/demo/
Purely based on my experience/opinion...
You'll end up changing your database design a couple of times as you build your app.
I would start with a whiteboard, then consider using a schema designer as #aram mentioned.
After you see the big picture, just start with the relationships that what you need for today's features. You can keep referring to the original design, so you can see the bigger picture, but you don't want to overbloat your architecture before you need to because it will change.
After you write some code and build those relationships, you can spot check yourself using the rails-erd gem to programmatically generate your app's schema.
I was looking at graph databases and Neo4j. As suggested, I tried to draw a simple social networking graph on white paper and after a few sketches I stucked at some similar points.
At first I designed a social network where "user"s can "like" "post"s.
(u1:User)-[:LIKED]->(p:Post)<-[:POSTED]-(u2:User)
Now I want to notify user2 about the like action and draw this on the white paper.
(u1:User)-[:LIKED]->(p:Post)<-[:POSTED]-(u2:User)
| ^
|__________[:NOTIFY]_________|
I am not sure if it is clear but I just drew a relationship between a node and another relationship which is not possible for graph databases, at least for Neo4j. So I decided, a Like should be a node instead of a relationship. Then my graph turned into this.
(u1:User)-[:CREATAD]->(l:Like)-[:BELONGS_TO]->(p:Post)<-[:POSTED]-(u2:User)
| ^
|__________________[:NOTIFY]________________|
Now everything is OK. Then I added Comments feature to the system as a relationship but when notifications involved, again it turned into a node. And same happened when I added "Liking comments" feature, "Likes to Comments" first seemed they are relationships but once again they turned into nodes when notifications involved.
In general, at some point I find myself drawing a relationship between a node and another relationship. My solution to that feels like I am turning entities, which naturally look like relationships, into nodes. And this makes me think of I have some problems with deciding what should be a node and what should be a relationship.
So my question is, does anyone else other than me fall into this "relationship between a node and another relationship" issue and if so how do you solve that?
It all depends on your use-cases, in many cases a simple relationship is good enough but if you want to do more with that entity or fact you turn it into a node, oftentimes it turns out that it is an actually quite important concept in the domain.
In our data modeling class there is a specific section on this and also in the "Graph Databases" book it is discussed in detail (you can get the free PDF here).
Sometimes it makes sense to keep the original relationship around for a fast shortcut crossing over that intermediate node if you don't need that detail.
Let's say I have an existing database with about 90 tables. I've seen comments that state including them all into one big edmx file is not considered good practice. Suppose I have logical groupings like HR, Legal, and Accounting that I can use to create multiple edmx files. That makes sense. However, what I don't know is what to do if each of these logical groupings would contain a foreign key to commonly used tables (like employee, address, etc). Should each edmx file contain these tables as well, or is there a better way to handle this?
On a side note, when creating an edmx file, how small is too small? Is a context with 5 entities too small? 2? Is there a general rule of thumb?
Any guidance is appreciated!
From the runtime perspective it should not really matter whether you split your model to multiple edmx files or not. 90 entities should be fine but you may start seeing some delay when your app starts. If you experience this you may want pregenerate views which should address the issue. The EF designer is known to be slow if you have many entities. The EF Designer in VS 2012 however allows to have multiple diagrams per model to visualize subsections of your overall model.
If you think you will be able to manage the model easily without splitting it then you can try going with just one model. If it becomes unmanagable then you can think about splitting.
I wrote a few assumptions regarding Entity Framework, then a few questions (so please correct where I am wrong). I am trying to use POCOs with EF 4.
My assumptions:
Only one data context can exist for an EF diagram.
Data Contexts can refer to more than one entity.
If you have two data sources, say MS SQL server and Oracle, EF requires two different diagrams to access the data.
The EF diagram data context is the "Unit of Work", having a single Save() for anything on the diagram. (Sure you could wrap it in a UnitOfWork class, but it essentially has the same duties).
Assuming that's correct, here are my questions:
If you don't keep all entities on the same EF diagram, how do you maintain data integrity, like "Orders" cannot exist without a "Customer"? Is this solely a function of the repository to load data just to verify integrity, or do we "try/catch" on database referential integrity errors?
Wouldn't you create an EF diagram for each Entity? For example, I wouldn't expect changes to a customer and changes to a product to be written together as they have nothing to do with each other (having them on the same diagram would cause them to be written together). Or is the scope of an EF diagram to encompass all similar entities stored in the same storage medium?
Is it the norm to divide up the entities like that, or just have a single diagram holding all the entities? I would think the latter, but the thinking is getting the better of me.
Having one big EDM containing all the entities generally is NOT a good practice and is not recommended.
Using one large EDM will cause several issues such as:
Performance Issue in Metadata Load Times:
As the size of the schema files increase, the time it takes to parse and create an in-memory model for this metadata would also increase.
Performance Issue in View Generation:
View generation is a process that compiles the declarative mapping provided by the user into client side Entity Sql views that will be used to query and store Entities to the database. The process runs the first time either a query or SaveChanges happens. The performance of view generation step not only depends on the size of your model but also on how interconnected the model is. If two Entities are connected via an inheritance chain or an Association, they are said to be connected. Similarly if two tables are connected via a foreign key, they are connected. As the number of connected Entities and tables in your schemas increase, the view generation cost increases.
Cluttered Designer Surface:
When you generate an Edm model from a big database schema, the designer surface is cluttered with a lot of Entities and it would be hard to make sense of how your Entity model in total looks like. If you don’t have a good overview of the Entity Model, how are you going to customize it?
Intellisense experience is not great:
When you generate an Edm model from a database with say 1000 tables, you will end up with 1000 different entity sets. Imagine how your intellisense experience would be when you type “context.” in the VS code window.
Cluttered CLR Namespaces:
Since a model schema will have a single EDM namespace, the generated code will place the classes in a single namespace.
For a more detailed discussion, have a look at Working With Large Models In Entity Framework – Part 1
Solution:
While there is no out of the box solution for this but it suggests that instead, you should Naturally Disconnected Subsets in your model meaning that based on your domain model, you should come up with different sets of domain models each containing related objects while each set is unrelated and disconnected from the other one. No Foreign Keys in between could be a good sign for separation. And this make sense because in a large model, usually your application does not require all the tables in a database to be mapped to one Entity Model in order to work.
Even if this kind of separation is not 100% possible - meaning that there are subsets of tables that have out going foreign keys to other tables in the database - it still encourages you do separate them. When you do this, you would have to take the responsibility of setting the foreign key appropriately. There would be no navigation property that allows you to get the Entity that represents this foreign key. Of course you could manually query for this Entity in the other container if needed.
Also, for some tips and tricks on how you can split one large entity model into smaller ones while reusing types, take a look at: Working With Large Models In Entity Framework – Part 2
About your question: Order and Customer belong to the same natural domain and should be kept in the same EDM. Like I said, you can scatter them over 2 different entity data models but then you have to take the responsibility of setting the appropriate foreign keys or you'll get runtime exceptions, by the same token, Customer and Product should be kept in separate entity data models. Following these rules, you can come up with a well defined domain set design in your data access layer.
I realize that this question was about EF4 but I am sure that many people who are just now "making the switch" will end up here via Google and will read this and the approved answer and make decisions based on it even though they are using EF5 (or EF4.4 if you are stuck on .Net 4.0)
EF5 allows multiple diagrams per edmx. This is a big deal, at least to my team, because it allows us to visually separate entities without requiring separate edmx files. Dr. Zim's points are all still valid except (obviously) the "cluttered designer surface".
There are draw backs to having multiple edmx files, the biggest one is that even if you create separate namespaces for each, you cannot duplicate entity names. Yes, if you truly are designing your system "code first" then this should not be a problem. However, many (most) of us are adding EF to existing systems that are already built on top of relational databases which have normalization.
"But normalization is a good thing, right?" Well, if you are using a relational database yes. "But why does that matter if I am using EF?" A common "normalized" table is Address. Possible scenario: Company (location of business/office) and Contact (might be "remote" worker so they are not at the business location) and they both have a FK that points to Address. Using one edmx file for Company and one for Contact (even with different namespaces) that both include the Address table, the code will compile but at run time you will get this beauty:
Multiple types with the name 'Address' exist in the EdmItemCollection
in different namespaces. Convention based mapping requires unique names
without regard to namespace in the EdmItemCollection
You can change the mapping that is used by EF but then you have other "issues" when working through implementation and most people use the default mapping so forums like this won't have many pertinent questions and answers.
You could also rename the Model name for the Address table to "ContactAddress" and "CompanyAddress" respectively, but that gives the illusion that they are different types when they really aren't. OK, so they are different types in EF but not in the database and, as I said, most of us "live" in the world of tacking on EF to an existing system with an existing data store that is a relational database.
This is already a long-winded "answer" so I will stop here. I just wanted to make sure that people who landed here because they searched for "multiple edmx" and did not realize that there are significant difference between EF4 and EF5 were made aware and realized they may need to do some more investigating.
So I have a layered ASP.NET MVC proof-of-concept application with good separation between presentation concerns, business logic, and infrastructure concerns. Right now it is operating off of a fake repository (i.e. LINQ queries against static IQueryable objects). I would like to create a functional SQL repository now.
That said, I don't want to simply tie it into a database that has a 1-1 mapping between tables and entities. That wouldn't meet the business need I am hoping to solve (partial integration with existing database - no hope for convention over configuration).
Do you have suggestions for which ORM / mapping tools I should consider and/or avoid?
Do you have suggestions for articles/books I could look at to help me approach this topic?
Would it be better to simply use parameterized queries in this scenario?
Entity Framework in version 4 would definitely allow you to:
have a mapping between the physical database schema and your conceptual schema, e.g. having an entity mapped to several tables, or several tables joined together forming a single business entity
grab data from views (instead of tables directly)
use stored procedures (where needed and appropriate) for INSERT, UPDATE, DELETE on every entity
NHibernate sounds like a good fit for what you are looking for. You will be able to make your repositories call queries in either HQL or using the API, either way you can get to your database and shape the data to fit the way your repository is being used. It will always be hard to make a square peg fit into a round hole though. SO has lots of nice support when you get into using NHibernate, good luck.
As you mentioned in the question, it is very debatable to choose an ORM. Different people will have different project needs. I am not exactly sure what will take priority for you. Here is what I have tried myself.
NHibernate seems to be the most commonly used ORM in DotNet projects. I feel it suffers from a typical open source problem. It offers so many features but the documentation really sucks. If you have lots of time at your disposal you can give it a shot.
Another options is to go for something like Entity Framework. Its very easy to set up and get up and running. With version 4.0 and the CTP there is provison for code first as well as fluent mapping and configuration. Since you have said you would want to keep the domain model separated EF 4 will help you because it has a notion of conceptual model which is an abstraction over the mapping layer.
You can refer to few links below for the blogs I had written based on my experience
http://nileshgule.blogspot.com/2010/08/entity-framework-hello-world.html
http://nileshgule.blogspot.com/2010/09/nhibernate-code-first-approach-with.html
http://nileshgule.blogspot.com/2010/09/entity-framework-first-query-using.html
http://nileshgule.blogspot.com/2010/09/entity-framework-learning-series.html