Not really sure what the folks you're talking to locally mean by 'OLAP database'. To me, this would 'normally' indicate that you're talking abotu a database housed/running within an OLAP engine (which, SQL Server is not, SSAS is though). 'Typically' (assuming by typical one means you subscribe to the Kimball approach to data warehousing), the schema of a datawarehouse (or even data mart) will typically be reflected (almost identically) within an olap database - that is, if the relational DB has (one or more) fact and dimension tables, the OLAP DBwill have the same.

My personal approach is generally to distinguish components of a BI solution as such:

-- Datawarehouse and/or datamart - these are stored in an RDBMS (SQL, Oracle etc).With newer tech though (ie columnar db's) this isn't always the case.

-- 'cube' or multidimensional Database - typically stored in an OLAP engine (e.g. SSAS, Hyperion etc)

With the newer tech such as columnar DB's, the lines are blurring though. Where we once used to always aim to have an EDW or DM in a traditional RDBMS, the need for this has decreased to an extent - where the DW may be in a columnar (maybe even in memory) DB and client tools are also querying this directly (versus the push to OLAP and cube querying tools).

To answer your last question - I would never consider a cube (or OLAP DB) as a 'warehouse' ("possibly" a datamart, but often not that either). Mainly because (to me) these are not necessarily permanent - I can build almost any delivery dataset I want if I have the relational DB still. Having said that, from the very first BOL, Microsoft often referred to the cubes (in OLAP services, back in SQL7 and 2000) as datamarts and/or warehouses.