We are designing a SQL Server database with link tables for many-to-many relations.
The question is are there any best practices for naming these kinds of tables for use with the entity framework?
Let's say there's a table
Customer
and
Address
Then there is a link table between them, what do we call it?
CustomerAddress ? Or something else?
Thnx
For example, users - UsersInRoles - Roles. If CustomerAddress does not contains anything except CustomerID and AddressID, EF'll generate only two entities Customer (with Addresses property) and Address (with Customers) and there is no any matter how you call this intermediate table
Related
I'm playing around with entity framework and code first approach. The scenario is this:
An user can have multiple companies (each company has an address)
An user can have multiple houses per company (each house has an address)
I'm thinking of two ways I can manage addresses:
Have an Address table with a column for CompanyId and HouseId (for companies addresses only CompanyId will be inserted and for houses both Ids will be inserted.
Have a CompanyAddress and HouseAddress tables with the only difference between them being the FK for CompanyId versus HouseId.
How would you do it? Is there any other, better options?
In EF Core you should use Owned Entity Types for this. In EF 6, use a Complex Type. Both allow you to have an Address type in .NET without having an Address table in your database.
My Entity Relationship Diagram
My ER diagram designed for the Orders database about customers and their orders for
a company. Each item
in the database must have an “owning” salesman, whether or not it is being ordered.
With that being said I was wondering whether there were any issues with my diagram? What do you suggest I should change?
Should I remove the customer and salesman attributes?
I not sure but I think in your the Address Entity is extra its a attribute customer only so why you create address as a separate attribute.
Please refer the attach image to correct your different relationship with attributes.
I have a question, with regards to how do you create the relationships between members of two different entities?
For example, in case of 1:1 you can create a domain-based attribute that is referencing the entity.
But in case you have a customer with multiple addresses, and you have an address entity.
When you update the member of the Address attribute of the Customer entity, based on the 1:M how would we be able to surface that relationship and connect the Address entity to the Customer entity?
So in case an Address member in the Customer entity changes, how would that update process work since we don't have a mapped relationship?
I know in M:M you would use a bridge table. And in the MDS database which table would contain that relationship info?
Any suggestions to articles and blog posts/Videos or ideas, would be greatly appreciated.
Thanks,
Andrea
In MDS (Master Data Services), you can use the Hierarchy feature.
- Option 1: create Explicit Hierarchy
If you're using SQL Server 2012 (possibly 2014 too), then an Explicit Hierarchy will solve this.
(see: Explicit Hierarchies (Master Data Services) )
Basically, you will be able to use Customer entity rows as parent nodes in the hierarchy (think of a tree structure) and assign one or more Address entity rows as child of each Customer.
As the name suggests, this needs to be "explicitly" managed.. means either someone will do this manually (drag-drop) using the MDS Hierarchy UI page or you can use an SSIS package to automate it while loading the staging table.
(see: Move Explicit Hierarchy Members by Using the Staging Process (Master Data Services) )
NOTE: Explicit Hierarchies have been Deprecated (starting SQL 2016 ...I think)
- Option 2: create Derived Hierarchy (bridge table- M:M)
This is similar to the bridge table concept that has been suggested earlier for M:M relationship, but in the MDS context.
Create another entity, call it CustomerAddressRelationship (let's say), let's call it CAR for now.
Add 2 Domain Attributes to CAR: one referring to the Customer entity, the other to the Address entity.
Now, if you want, you can create a Derived Hierarchy on this CAR entity in the format CAR > Customer > Address.
Read more about Derived Hierarchies: Many-to-Many (M2M) Relationships
- Option 3: create Derived Hierarchy (1:M)
Don't create CAR. Just add a column CustomerID (let's say) to the Address entity. This way every Address may have 0 or 1 Customer related to it.
Create a Derived Hierarchy for 1:M Relationship
Hope this helps.
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.
Seems I am not allowed to post images, so let me describe the image. It is a SQL table diagram showing the relationships between 4 tables. The Tables are:
People
Id
FirstName
LastName
PhoneNumbers
Id
Number
PhoneNumberTypes
Id
Name
Description
PeoplePhoneNumbers
PersonId
PhoneNumberTypeId
PhoneNumberId
The two main tables are People and PhoneNumbers. There is also a PhoneNumberTypes that describes the type of PhoneNumber (Home, Work, etc).
The PeoplePhoneNumbers table serves as a Many-To-Many relationship table between People and PhoneNumbers. However it also connects to PhoneNumberTypes to describe the relationship.
I have been trying to figure out how to handle this Entity Framework because EF does not allow you to add additional information to the Association(Many-To-Many) Table.
Besides the PhoneNumberType info, I also find that their are additional data pieces I need to record in the Association Table like "Start Date", "End Date", etc.
The only solution I have come up with so far is to create an entity in EF that combines the fields in PhoneNumberTypes, PhoneNumbers and PeoplePhoneNumbers into a single entity. Then use SQL stored procedures for CRUD operations against it.
I would prefer a more EF centric solution. Does anyone know of one?
PhoneNumberTypes should not be linked to PeoplePhoneNumbers. Let PeoplePhoneNumbers be what it is and only a junction table. PhoneNumberTypes should be linked to PhoneNumbers. EF should be able to create this setup by convention. Additional information describing phone number should also be linked off of PhoneNumbers. This design adheres to more Domain Driven Design (DDD) principles and also generates a better database design as well.