I'm wondering if there's a general term used for objects that map exactly to data tables? E.g., a user and an article objects could map directly to user and article tables in a db, with each db field corresponding to a class variable...
They are referred to as Entities in JPA specification.
They are usually called entities, but entities in general don't need to map 1:1 to DB tables. However, what you describe is known as Active Record pattern.
Also, please note that there is very rarely an exact 1:1 mapping between object model and DB:
many-to-many relationships are usually implemented with third table in the DB but are usually mapped to only 2 classes with direct associations in the object model (if relation doesn't have additional attributes)
class inheritance can be modeled in 3 different ways in the DB with 1, N or N + 1 tables
ternary relationships use 3 tables in DB, but can be modeled with parameterized properties in the object model
Related
I have a lab entity with two multi-valued attribute nested inside the entity (rooms attribute that contain hardware attribute) and I need to represent it in ERD then in relational schema.
so the problem is like :
is the above representation right ?
one another way I tried to solve this problem is by making the rooms a weak entity to the lab and the hardware a weak entity to rooms like :
what is the best way of these two and is there a better idea ?
and how to map this in relational schema ? because the way I think about it I think it would take 3 tables to represent it either ways.
My model looks like this:
InsurancePolicy
VehicleInsurancePolicy
AbcInsurancePolicy
DefInsurancePolicy
HomeInsurancePolicy
GhiInsurancePolicy
PqrInsurancePolicy
SomeOtherInsurancePolicy
... etc
where InsurancePolicy is an abstract class which is the base class for all concrete implementations of insurance policies. AbcInsurancePolicy , DefInsurancePolicy , etc are implementations which correspond to a certain insurance products. Sometimes I define other abstract classes for subgroups of policies with a subset of common fields (like VehicleInsurancePolicy).
I mapped this classes using a "Table per subclass, using a discriminator" strategy. The InsurancePolicy table contains about 60 fields, and each joined table adds from 10 to 30 fields. I used this strategy because:
I have a lot of subclasses with a lot of fields. A table-per-class-hierarchy strategy would end having a single table with a lot of null columns.
I want to be able to extend the application by adding other subclasses without changing the schema of InsurancePolicy table.
The InsurancePolicy is used often as a many-to-one relationship in other entities like Payment, Document etc.
NHibernate generates a lot of left-outer-joins when querying for InsurancePolicy because it doesn't know the type. This is very inefficient as I have a lot of tables to join. The problem becomes even worse when lazy-loading many-to-one properties containing an InsurancePolicy because it is used quite a lot in my model. The concrete implementations are used rarely, only in edit/details scenarios where it is specified the actual type and only the needed tables are joined.
Then I used a combination of discrimator + join. Thus the InsurancePolicy table contains the information about the type. Unfortunately a "join" mapping doesn't support lazy-loading. I tried setting fetch="select", however these generates N+1 selects when querying for multiple insurance policies.
// select from 1 table, "join" class must be lazy-loaded on access
Session.Get<InsurancePolicy>(5)
// select includes a join, since we explicitly specified a concrete type
Session.Get<SomeConcreteInsurancePolicy>(5)
So my questions are:
Is there a way to extend NHibernate to make it work like above?
Is there another way of mapping these large / complex class hierarchies?
Based on this:
The concrete implementations are used rarely, only in edit/details scenarios
I recommend that you break up InsurancePolicy in two:
InsurancePolicy, containing only the properties from the current base class
PolicyDetails, an abstract base class for the hierarchy.
There's a one-to-one relationship between those two classes.
The beauty of this is that you don't have to change anything else (except a minor change in the policy edit views, to point them to the new relationship)
I often see "linking" tables for M:N relationship, where N can be 1..X types of entities/classes, so that the table contains classNameId referring to ClassName table and classPK referring to the particular Entity table.
How is this called ? Does it have an alternative with the same effect without having the EntityName table ?
In the ER model, entities and subentities can be related by inheritance, the same way classes and subclasses are in an object model. The problem comes up when you transform your ER model into a relational model. The relational model does not support inheritance as such.
The design pattern is called is called generalization-specialization or gen-spec for short. Unfortunately, many database tutorials skip over how to design tables for a gen-spec situation.
But it's well understood.It looks quite different from your model, but you could create views that make it look like your model if necessary. Look up "generalization specialization relational modeling" for explanations of how to do this.
The main trick is that the specialized tables "inherit" the value of their primary key from the PK of the generalized table. The meaning of "inherit" here is that it's a copy of the same value. Thus the PK in each specialized table is also an FK link back to the correpsonding entry in the generalized table.
Could someone explain me the object model in Database ? For eg in case of the forums
how would my object model look like for the below tables for designing Internet forums (Not the complete implementation). I want the basic idea regarding object model and how is it different from ER diagram which is based on relational model.
users Table
user_id
forums Table
forum_id
forum_name
topics Table
topic_id
forum_id
user_id
topic_name
I understand your question like this: What is the difference between objects and tables? Now, there is no object model in databases (in relational databases, there are also object oriented databases). As you have said yourself there is a relational model.
A table consists of rows and columns (or in old language records and fields). An object consists of data and methods. A table often has primary key as one of its columns (or several columns). A table often has foreign keys used to reference to other rows in other tables or the same table.
In objects you may reference to other objects of the same class or of other classes but this is not the same.
So if you have the above 3 tables and then you write classes representing the content of one row of each table and the classes know how to become persistent by writing into the database table and how to create a object of a class by getting the content from a database table then you are in a chapter where the space of the answer box is not enough.
This is the topic of how to make objects persistent. How to convert object model to relational database model etc. The web is full of discussions about it and there are lots of frameworks, depending on what language you are working in and there is support from databases to this and there is support from languages to this etc.
Also maybe somebody designs the above tables differently in classes and says I want each table be one class and each row be another class ... why not. Probably a good idea. There are many techniques to create data access objects.
I'm reading Pro JPA 2. The book talks begins by talking about ORM in the first few pages.
It talks about mapping a single Java class named Employee with the following instance variables - id,name,startDate, salary.
It then goes on to the issue of how this class can be represented in a relational database and suggests the following scheme.
table A: emp
id - primary key
startDate
table B: emp_sal
id - primary key in this table, which is also a foreign key referencing the 'id' column in table A.
It thus seems to suggest that persisting an Employee instance to the database would require operations on two(multiple) tables.
Should the Employee class have an instance variable 'salary' in the first place?
I think it should possibly belong to a separate class (Class salary maybe?) representing salary and thus the example doesn't seem very intuitive.
What am I missing here?
First, the author explains that there are multiples ways to represent a class in a database: sometimes the mapping of a class to a table is straightforward, sometimes you don't have a direct correspondence between attributes and columns, sometimes a single class is represented by multiples tables:
In scenario (C), the EMP table has
been split so that the salary
information is stored in a separate
EMP_SAL table. This allows the
database administrator to restrict
SELECT access on salary information to
those users who genuinely require it.
With such a mapping, even a single
store operation for the Employee class
now requires inserts or updates to two
different tables.
So even storing the data from a single class in a database can be a challenging exercise.
Then, he describes how relationships are different. At the object level model, you traverse objects via their relations. At the relational model level, you use foreign keys and joins (sometimes via a join table that doesn't even exist at the object model level).
Inheritance is another "problem" and can be "simulated" in various ways at the relational model level: you can map an entire hierarchy into a single table, you can map each concrete class to its own table, you can map each class to its own table.
In other words, there is no direct and unique correspondence between an object model and a relational model. Both rely on different paradigms and the fit is not perfect. The difference between both is known as the impedance mismatch, which is something ORM have to deal with (allowing the mapping between an object model and the many possible representations in a relation model). And this is what the whole section you're reading is about. This is also what you missed :)