Using Areas in MVC 4.5 can be hazardous to your health if you are starting out.

My original Idea for a model in SQL 2012 was to create some schemas. In each schema name I had worked out a way to separate out some important business functionality in discrete business units like so: Finances, Inventory, Shipping, Contacts, Admins, Management, Products.

Once these schemas were created in the database and there were associated tables under each distinct schema.   Now image trying to create mvc areas to match your schema definitions on a one to one basis.  I quickly found out that areas are not good at sharing information between one another.  They are completely separate and you really can't share ActionResults between areas in mvc4.5 with the default routing engine.  You are basically stuck with the data that you use in your areas.

I left out the controller and views as it doesn't apply to areas and sql 2012 schemas at a high level.

My initial model in mvc areas looked like this Model only file structure:

Notice that
Mvc Project
    Areas
           Financies Area
                Models
                    Finances.edmx  // Only points to 
            Inventory Area
                Model
                    Inventory.edmx // only points to Inventory items
            Shipping
                Model
                    Shipping.edmx / only Shipping stuff
            Contacts
                 Model
                     Contacts.edmx
             Admins
                  Model.
                     Admins.edmx

The above is completely unrealistic as no schema information can share any data between itself and other areas of the business.  This is a pure separation of concerns and is so unrealistic that it is doomed to failure.
...

The problem is you can't access data between different schema items using the Entity framework for each area.

To solve this I combined Schemas under the models folder like this:

Mvc Project
    Areas
           Financies Area
                Models
                    Admin.edmx
                    Management.edmx
                    Shipping.edmx (subset)
                    Inventory.edmx (subset)
                    Finances.edmx  // Only points to 
            Inventory Area
                Model
                    Admin.edmx
                    Management.edmx
                    Shipping.edmx (subset of shipping)
                    Inventory.edmx  // only points to Inventory items
            Shipping
                Model
                    Admin.edmx
                    Management.edmx
                    Shipping.edmx
            Admin
                 Model
                    Admin.edmx   (Notice in this model only Admin stuff needs Admins to make changes to itself)
            Management
                  Model
                    Admin.edmx
                    Management.edmx
            ...

Obviously Management and Administration may be involved in all business areas, but Shipping obviously won't be involved in Finances b/c Shipping does need to know what the finances are in order to ship something in most businesses but finances needs to know how much stuff was shipped in order for it to balance its finances.  And then Finances may need to tell Shipping that your only have $500.00 per week for shipping expenses using this model.

This doesn't solve the problem of compartmentalization, but a developer could potentially take this to the next level and perform compartmentalization by between schemas and areas for their work force by adding an subtypes of each schema like so:

Mvc Project
    Areas
           Financies Area
                Models
                    OutsideContractorAdmin.edmx
                    TrustedAdmin.edmx
                    LowlevelAdmin.edmx
                    Management.edmx
                    Finances.edmx  // Only points to 
            Inventory Area
                Model
                    OutsideContractorAdmin.edmx
                    TrustedAdmin.edmx
                    LowlevelAdmin.edmx
                    Management.edmx
                    Inventory.edmx // only points to Inventory items
            Shipping
                Model
                    OutsideContractorAdmin.edmx
                    TrustedAdmin.edmx
                    LowlevelAdmin.edmx
                    Management.edmx
                    Shipping.edmx


The problem having multiple edmx files of the same set of entities in it is that the structure of the database when changed would need to be updated for that schema in each area.  And all the code for each area that utilizes those updates would need to be fixed.  But the code changes would be relative to the specific areas of work required to update the code and could more easily be controlled.  But work could be coordinated on a single section of the code.

Compartmentalizing development could be constructed in the same development where outside contractors might work on low level stuff, but where maximum trust is required because it would be developed by an internal developer or trusted contractor where work is much more critical to the operation of a company.