Analysis on the number of entity classes generated when ADO. NET Entity Framework is used less than the number of data tables

When you generate an ADO. NET Entity Data Model (Entity Data Model) through a database, the number of entity classes generated may be less than the number of data tables. The following describes two possible causes.
1. All columns of the data table can be empty.
When a data table has a primary key, the object data model uses the primary key as the entity key to identify an object. If the data table does not contain the primary key, all columns that cannot be empty are Entity keys, they are used together to identify an object. When all columns in a data table can be empty, an object cannot be identified. Therefore, the object data model does not contain this object class. You only need to add a primary key or non-empty column to the table and it will appear in the object data model. In addition, when using the ADO. NET Entity Framework, tables without primary keys are prone to some strange errors. Try to set a primary key for each table.

2. All columns in the data table are foreign keys.
When all columns in a data table are foreign keys, the object data model intelligently connects the primary key tables in these relations directly through navigation attributes.
The following is an example. There is a foreign key relationship between the account table and the accountpermission table. The account table ID is the primary key, and the accountid of the accountpermission table is the foreign key. The permission table and accountpermission table have a foreign key relationship. The permissionid of the permission table is the primary key, and the permissionid of the accountpermission table is the foreign key. The database relationship diagram is as follows:

This is because the accountpermission table does not appear in the object data model. The account table and the permission table directly use the navigation attribute.

This is normal and there will be no inconvenience in use, but beginners may feel that a data table is lost. In fact, as long as permissionid is regarded as an attribute of the account, this transformation can be understood. If you want to modify the value of permissionid in the accountpermission table, you cannot simply account. permission. permission = (the modified value). Instead, select a permission object with permissionid = (the modified value) and use the object as the account's permission object.

This article applies to. NET Framework 3.5 SP1