The document discusses different approaches to structuring an entity data model in Entity Framework including table-per-type and table-per-hierarchy inheritance. Table-per-type stores each entity type in its own table to avoid data redundancy but has worse performance. Table-per-hierarchy stores all entities in one table for better performance but introduces data redundancy. It also covers model-first, database-first, and code-first approaches to implementing an entity data model in Entity Framework.
The document discusses different approaches to structuring an entity data model in Entity Framework including table-per-type and table-per-hierarchy inheritance. Table-per-type stores each entity type in its own table to avoid data redundancy but has worse performance. Table-per-hierarchy stores all entities in one table for better performance but introduces data redundancy. It also covers model-first, database-first, and code-first approaches to implementing an entity data model in Entity Framework.
data model Structuring the data model using Table-per-Type and Table-per- Hierarchy inheritance
The inheritance mechanisms for an entity model.
Table-per-Type Table-per-Type inheritance is accomplished by modifying the conceptual model Architecturally, a separate database table is used to maintain data for non-inherited and key properties in the hierarchy. Table-per-Heirarchy Table-per-Type Advantages Data is not stored redundantly. Data is structured in third normal form so data integrity is improved. A much simpler implementation. Adding or removing an entity can be accomplished by simply adding or deleting the underlying table in the database. Disadvantages There is a performance decrease, particularly around CRUD operations. Makes database administration more complicated because of all the additional tables in the system. Table-per-Hierarchy Advantages Fewer database tables leading to a simplified database schema. Notably faster CRUD operations in most cases. (This is because all of the data is stored in one table.) Disadvantages There is necessary data redundancy, and because one of the main purposes of normalizing data is to remove redundancy, this is not a small issue. Data integrity issues are more likely because of data redundancy. Because of the data model, complexity is increased. Choosing and implementing an approach to manage a data model (code first vs. model first vs. database first) Model First You can create an empty model and then add entities to it. As you add these entities, you can define relationships between them and control how they behave. After you define your EDM, you can select to generate a database from the EDM; And the EF handles the database creation, the object/entity creation, and the mapping between them for you. The model-first approach was introduced in EF version 4.0 and Visual Studio 2010. It is an extremely powerful and useful paradigm, although it is not always feasible. Database First You can access any visible database object and generate an entity set from it. Again, the EF handles the creation of the Entity items and all the mapping thats needed between them. You can take an existing model and change it as well. If the back end changes, you can regenerate the entities based on those changes, or you can visually edit the mappings between the new items and existing entity properties so that no breaking changes occur. The two approaches include starting with the database schema and using the designer as a starting point. The two approaches mentioned previously include starting with the database schema and using it as the basis of your model, or building a model and having the tools generate the database. The last thing you need to do is click inside the designer surface and then right-click and select Properties. Youll see the Properties grid, which has several options about the model youll want to take note