Actually no. The basic database concepts will apply and you have to know some basic rules of what databases can do or else you'd face significant performance issues.
Entity Frameworks are useful to handle the conversion of mapping data from database records into objects. This allows developers to not have to deal with creating data access objects because the framework does it for you already.
So this will do quite a bit for developers especially when persisting data.
Looking up data can be performed with entity frameworks as well, but lookups are not always best done with just entity frameworks alone because if done improperly you will have memory issues when someone decides to load up the entire database into memory. Or I/O issues if someone decides to do queries inside another query. (Those two are the common performance issues I see when I review other people's code).
Sometimes it may be that you need raw SQL, stored procedure or a database view in order to get the best performance/maintainability ratio.
As such a good DBA is a valued resource. Although I try to relegate the database to be just a data store, they still need to perform tuning so the proper indices and storage allocation is done correctly.
One thing that entity frameworks allow me to do is to talk about objects and tables with the DBA in logical terms rather than physical terms. It allows application development and database to form a contract in the form of an Object Relational diagram that they agree to reduce the chances of defects (or at the very least quickly assign the blame).