I am not sure if I should be asking this here or at the programmers site. I came across "objectified relationship" while researching recursive saving in llblgen framework...I then searched stackoverflow (yes, first) and then google. I then came across a brief (related) topic on nHibernate.
I have an idea what it is but is there a detail description or explanation on it?
The relationship is an object itself, not just a connection. In a database the relationship would be represented as a row in a table rather than just as a UID in a column referencing another table. In a graph the relationship would itself be a node rather than 'just' an edge.
Related
I'm very new to Core Data and I have two questions:
I want that all of my Patient entities have property bed which is a value of type bed... Can I create an entity for that too and connect always one patient with one bed?
I wondered if I can do something like every Patient has a property doctors, and that would be a array of doctors "[doctor]". How could I make this.
Thanks, hope you know what I mean, it would be great If someone knows how to do that.
Okay Larme and Joakim Danielson answers my question as comments under my post :)
Their comments:
Yes. The key word you are missing is "relations". You want relationship between your entities. Be it one to one, one to many, many to many. –
Find an online tutorial on learning and using Core Data, many of them handles entity relationships as well –
I work in cattle production and I am learning about database design with postgreSQL. Now I am working on an entity attribute relationship model for a database that allows to register the allocation of the pastures in which cattle graze. In the logic of this business an animal can be assigned to several grazing groups during its life. Each grazing group in turn has a duration and is composed of several pastures in which the animals graze according to a rotation calendar. In this way, at a specific time, animals graze in a pasture that is part of a grazing group.
I have a situation in which many grazing groups can be assigned to many animals as well as many pastures. Trying to model this problem I find a fan trap because there are two one-to-many relationships for a single table. According to this, I would like to ask you about how one can deal with this type of relationship in which one entity relates to two others in the form of many-to-many relationships.
I put a diagram on the problem.
model diagram
Thanks
Traditionally, using a link table (the ones you call assignment) between two tables has been the right way to do many-to-many relationships. Other choices include having an ARRAY of animal ids in grazing group, using JSONB fields etc. Those might prove to be problematic later, so I'd recommend going the old way.
If you want to keep track of history, you can add an active boolean field (to the link table probably) to indicate which assignment is current or have a start date and end date for each assignment. This also makes it possible to plan future assignments. To make things easier, make VIEWs showing only current assignment and further VIEWs to show JOINed tables.
Since there's no clear question in your post, I'd just say you are going the right way.
I have been looking into some Entity framework tutorials and I have come across the word Entity Graph. I haven't got a clear idea about this term and its use. Can anyone provide info on this topic like what it is and its use in the context of entity framework?
When instantiated objects are joined together in a relationship they are referred to as
a graph, or an entity graph. The Entity Framework has some important rules about how
graphs are maintained.
Example, if you have a User(Entity) graph that consists of a User with Roles, Features.
When you detach the User
The User will be disconnected from this graph and the releationship references (Graph edges) will be destroyed.
You cannot travel from User to Roles/Features, because the graph edges (releationships) are destroyed.
I recommend you buy the "Programming Entity Framework DbContext" book (author: EF-Queen Julia Lerman) and you will find there a good explanation:
http://shop.oreilly.com/product/0636920022237.do
Google is your best friend here:
See this article for general definition and explanation of graphs
See here for specific information on EF and entity graphs
In Jpa hibernate fetching entities with associtions has always been a question for performance. Lazily loading associations with in a transaction again and again results in n+1 select issues and to avoid such issues JPQL join fetch and Criteria api joins are used. But fetching data with these two also result in Cross join issues means Cross join of all table records are returned to apllication by hibernate. Also altering fetch variable defined in annotaions on entity level is also not a good option for some cases. Hence to solve the above two issues entity graphs has been intoduced. All nodes defined in entity graphs are always eager fetched irrespective of their definition on entity level. These graphs are passed as a hint to queries . By passing graphs as a hint Cross join issues are solved as well as run time alteration of fetch behaviour can take place. For code you can check my github repository :
https://github.com/vaneetkataria/Jpa-Hibernate/blob/master/jdbcToJpaMigration/src/test/java/com/katariasoft/technologies/jpaHibernate/entity/fetch/entitygraph/dynamic/MultiInstructorsDynamicEntityGrpahTests.java
I Googled to find tutorials and documentation on Entity Framework and read a couple of articles too. I referred to MSDN documentation also, but still I am not able to understand it clearly.
With a little that I followed is that:
(1) Each table along with rows are considered as a single unit.
(2) It provides a solution to sudden table name change without affecting the application.
(3) It reduces a lot of code.
Can someone explain me in a more easy way with illustrations? Please don't be too technical.
Check out:
Entity Framework Overview
Intro to Entity Framework with SQL Server
Beginner's Guide to Entity Framework (has lots of articles, videos, etc.)
It's rather hard to find something that's not too technical and just shows nice graphical representations.
But basically you have three "layers" inside an EF model:
the physical database model - what tables and columns do you have?
the conceptual model - the business objects / entities you want to work with (which can be very similar or quite different from your physical model)
the mapping layer that defines the mappings between those two worlds
Say I want to design a database for a community site with blogs, photos, forums etc., one way to do this is to single out the concept of a "post", as a blog entry, a blog comment, a photo, a photo comment, a forum post all can be thought as a post. So, I could potentially have one table named Post [PostID, PostType, Title, Body .... ], the PostType will tell what type of post it is.
Or I could design this whole thing with more tables, BlogPost, PhotoPost, ForumPost, and I'll leave Comment just it's own table with a CommentType column.
Or have a Post table for all types of post, but have a separate Comment table.
To be complete I'm using ADO.NET Entity Framework to implement my DAL.
Now the question what are some of the implications if I go with any route described above that will influence on my DB performance and manageability, middle tier design and code cleaness, EF performance etc.?
Thank you very much!
Ray.
Let me ask you this:
What happens if two years from now you decide to add a 'music post' as a blog type? Do you have to create a new table for MusicPost, and then re-code your application to integrate it? Or would you rather log on to your blog admin panel, add a blog type in a drop-down box called 'Music', and be on your merry way?
In this case, less tables!
Generally, life will be easier if you can have all the posts in one table:
less joins to perform
less tables to maintain
common attributes are not repeated between tables
code more generic
However, you could run into some issues:
if each subtype has a lot of its own attributes, you could end up with many columns - maybe too many for your DBMS
if a subtype has an attribute (e.g. a stored picture) that is expensive for your DBMS to maintain even when unused, you might not want that column in all rows
Should you run unto such an issue, you can create a new table just for the specific attributes of that post subtype - for example:
create table posts (post_id number primary key,
post_date date,
post_title ...); /* All the common attributes */
create table photo_post (post_id references posts, photograph ...);
In many cases, no such issues arise and a single table for all will suffice.
I can't think of any merit in creating a distinct table for every subtype.
The problem is similar to the question of how deep your hierarchy should be in an OO design.
A simple approach in OO terms would be to have a base class Post and children for BlogPost, ForumPost and so on. Comment could either be a child of Post or its own hierarchy, depending on your requirements.
Then how this is going to be mapped to DB tables is an entirely different question. This classical essay by Scott Ambler deals with the different mapping strategies and explains their advantages and disadvantages in a rather detailed way.