Coming from a database background, I can't say that I have ever expressly heard a DBA or database developer actually use the term "pattern" before in describing their schema design. "Design patterns" are really more of a programming concept and there is a good question on SO that explores this.
To be fair, you can certainly have design patterns on your database but I might argue that this can get you into as much trouble as help you. Design Patterns are tools for application programmers to help solve unique and varied problems. Relational Databases and
Set Theory on the other hand is more structured and centralized all around data integrity. Design best practices are generally accepted (i.e.
Normalization) so clever design models such as
EAV are typically frowned upon by die-hard DBAs.
Coming to your question around views, what is preferable is going to depend on what you are trying to do. You basically have two kinds of processing:
OLTP - OnLine Transactional Processing
OLAP - OnLine Analytical Processing
OLTP, unless you are using views as part of your security model (to restrict certain user role access), you really should only ever see views of the #1 variety above (the idea being that if your data is properly normalized, most worthwhile data models will require multiple joins as the entities have been separated to eliminate transitive dependencies).
OLAP, however, your views should be a part of your
Data Mart model. There are a lot of varied techniques on how to perform this with terminology and recommended best practices changing depending on the Business Intelligence Tools you use. The long and the short of it though is that you are transforming your data (usually through dynamic or materialized views) to create a data model which makes it easier for end users to extract information. The best way to do this is going to revolve mostly around what type of data you are using. But again your original data should be highly normalized so I would expect many more of the #1 variety over the #2.
TL;DR - Database best practices are generally more accepted than having a bunch of design patterns available to the DBA. Given this it would probably be worthwhile to spend some time reading up on generally accepted practices related to