Can someone tell me the easy way to explain the differentiation between an entity and a table in database?
Entity is a logical concept of relational database model. And table is used to express it, but there is a slight difference. Table expresses not only entities, but also relations.
For example, assume that you want to make a database of projects and employees of a company. Entity is a unit of information that has meanings by itself. In this case, there will be two entities - "Project" and "Employee". Each entity has its own attributes.
In relational DB model, there is another idea, 'relation'. If employees participate in several projects, then we can say that there is a relation with a name 'works_on'.
Sometimes, relation can have its own attribute. In this case, 'works_on' relation can have attribute 'start_date' and so on. And if this relation is M:N relation(Like this case: In project 1, there are 5 employees. Employee A works on two projects.), then you have to make an extra table to express this relation. (If you don't make an extra table when the relation is M:N, then you have to insert too many duplicated rows into both 'Project' and 'Employee' table.)
CREATE TABLE works_on(
employee,
project_id,
start_date
)
An entity resides in a table, it is a single set of information, i.e: if you have a database of employees, then an employee is an entity. A table is a group of fields with certain parameters.
Basically everything is stored in a table, entities goes into tables.
In a relational database the concept is the same. An entity is a table.
In OOP (Oriented Object Programming) there is a nice article in Oracle docs:
In general terms, entity objects encapsulate the business policy and
data for
the logical structure of the business, such as product lines,
departments, sales, and regions
business documents, such as invoices, change orders, and service
requests
physical items, such as warehouses, employees, and equipment
Another way of looking at it is that an entity object stores the
business logic and column information for a database table (or view,
synonym, or snapshot). An entity object caches data from a database
and provides an object-oriented representation of it.
Depending on how you want to work, you can create entity objects from
existing database tables (reverse generation) or define entity objects
and use them to create database tables (forward generation).
There is little difference between an entity and a table, but first we should define the concepts of “tuple” and “attribute”. I want to express those concepts with a table.
Here is an example of a table. As you can see it has some columns. Each column represents an attribute and each line represents a tuple(row). This is the employee table. In this example, the table is being used for representing an entity which is employee. However, if we create a new table named superior to specify the superiority relationship between those employees, it would be a table that represents a relation. In summary, we can use tables for representing both the entities and relations so entities and tables are not the same.
I have a project that is using EF6 Database first mapped to a SQL database. This is all new so I control the EF model as well as the database schema.
I currently have a table that I'll call Vehicle for simplicity. I use a discriminator column to get subclass Entities Car and Truck. This all works fine.
Now I need to do a 'soft delete' and move any deleted vehicles to a VehicleHistory table. (After trying this w/ EF i will probably use a SQL transaction). This needs to be reviewable so I need this history table mapped as well, but I would like to keep it within the inheritance hierarchy so its easily reused in other classes.
My idea was to create 'vehiclecurrent' and 'vehiclehistory' tables with FK's to Vehicle for shared columns. i would then use TPT in EF to get 'carcurrent','carhistory', ect... derived from my TPH classes(so e.g. carhistory->car->vehicle). This is not working and I get Error 3034: "Entities w/ different keys are mapped to the same row"
So my question is basically how can I pull this off? Will this approach work and how, or is there another way to accomplish this? Thanks!
Is there such a thing? I'm not implementing anything, I'm just creating an E-R Diagram from it. Here is a simple example:
ENT(Ent_ID, Group_IDs)
GROUP(Group_ID, Att)
The attribute Group_ID would have an one-to-many relationship with different instances of GROUP. (Is the word instance correct here?)
P.s: I know I could create a third entity with Ent_ID and Group_ID as attributes to make the relations if I was implementing it, but I don't know if this has to be specified in the diagram.
The way I understand your example, you have a one-to-many relation:
Each GROUP instance can have many ENT instances related, but every ENT instance is related to one and only one GROUP instance.
I have a junction object, "Purchase", with two master-detail relationships. One with Customer and another with Product. Now I need to add a master-detail relationship in Payment object with Purchase as a parent.
The problem is that when I try to create a new master-detail relationship the Purchase object is not available to select as a parent. I can do a Lookup relationship but not a master-detail.
Anyone know if there is a way of doing that or if there is a Salesforce limitation on that?
This is a Salesforce limitation. Unless an object is a master in all of its master-detail relationships, it can only participate in two master-detail relationships. In your case, you can get around this issue by converting any one of the three relationships on Purchase to a lookup relationship. Fortunately, new features in the Summer 12 release allow you to set lookup relationships as required and to perform cascading deletes on required lookups. If you were to set up on of the lookups in that way, the main piece of functionality that you would lose would be the ability to create roll-up summary fields on whichever object is no longer as master.
I have a database I'm working on the design for. I have manufacturers and I have distributors on separate tables containing practically the same information with few exceptions. Both groups have one-many contacts that need to be connected to them. I created a contact table to hold contact information, one!
Do I need a second contact table? I'm trying to make this as DRY as possible. How would that look? Thank you in advance
Maybe a case for the party-role pattern? Manufacturer and Distributor are roles played by Parties. Contacts apply to Parties, not the role(s) they play. So you'd have:
a table named Party
a table named ContactMethod (or similar)
a 1:M relationship from Party to ContactMethod
which would resolve the need for two Contact tables. How you model the roles side will depend on wider requirements. The canonical model would have:
a single supertype named Role
a M:M relationship from Party to Role
a subtype of Role for each specific role (Distributor and Manufacturer in your case).
(Note: as an aside, this also allows a Party to play both manufacturer and distributor roles - which may or may not be relevant).
There are 3 'standard' patterns for implementing a subtype hierarchy in relational tables:
table for entire hierarchy
table per leaf subtype
table per type
(1) would apply if you don't have any role-specific relationships. (However I suspect that's unlikely; there's probably information related to Distributors that doesn't apply to Manufacturers and vice-versa).
(2) means multiple relationships from Party (i.e. one to each role subtype).
(3) avoids both above but means an extra join in navigating from Party to its role(s).
Like I say, choice depends on wider reqs.
hth.