I am trying to decide how (or whether) my Data Access Layer should deal with existing security and integrity protections on the database. The architect in me says that separation of concerns is a priority and duplication of duties is wasteful so I should leave the database to handle access control and let the Object Relational Mapping be a dumb middle-man between the business logic and the persistence layers. But the DBA in me really doesn't like the idea of creating models that allow other developers to attempt to handle the underlying data in ways that they should not (as defined by constraints, relationships and account security on the database).How smart should my DAL be? Should my DAL take into account access privileges (such as who can read/write) to create an object-oriented accessible version of my persistence layer? Or should it be a true pass-through and should I expect my business-layer to respect security to which it may not have immediate visibility? More probably something in-between?In other words... if I have a database account which only provides SELECT (read-only) rights to table MYTABLE, should the Data Access Layer object for MYTABLE reflect these permissions in what methods are allowed to be called against this model? What about when I have a single entity which could be accessed in different ways depending on which account (or service) is hitting it? Should I have multiple models of the same underlying data?If you cannot tell from my wording above, I would prefer to have a smarter DAL that ensures my database controls are being at least somewhat respected (without the need to throw a bunch of runtime errors). But I don't know where to draw the line between business logic and data access logic and I hate the idea of duplicate work. 
Should Data Access Layer mirror my Database Configuration?
database;application design;separation of concerns;layers
This question seems like it pertains to your question in that it asks something that appears to be implied: should you create a database user for each user accessing the application. And my answer would be an Unreserved NO!With regards to primary keys and foreign keys, I'd highly recommend you implement both in your database, barring that it should fall upon your Data Access Layer.One anti-pattern I've seen (and that has been documented by many others) is the Anemic Model. Where your object mappings to the DB are little more than data transfer objects (setters and getters) that will be operated on by other elements in the application.Hibernate is a pretty powerful O/RM because it goes beyond just the mapping from the database to objects but it provides true persistence ignorance allowing your object models to be much more expressive of the business logic.For example instead of having some operation that takes a Customer and inserts an Order object using the customer id, you'd have a createOrder operation on the customer that adds a new order into your Customer.orders attribute and returns it so you can add line items to it before finally calling save on the context and everything go to the database in one fell swoop.Read about Domain-Driven Design to see how to make more expressive data layer that does more than just shuttling information back and forth from the database.