Question: What are the core elements when it comes to present a data model (logical one) (for example for a data warehouse). The relations, attributes, how it works? What is not useful to mention?

I'm trying to gather some information about that topic.

Answer: 
First, you must start to appreciate that there is a difference between a CONCEPTUAL model and a LOGICAL one.

CONCEPTUAL models can be drawn in the form of an ERD, UML class diagram, or various other modeling/drawing techniques. Such models are almost always incomplete, and that's deliberate, as such models are used for the specific purpose of highlighting only certain aspects of a system.

LOGICAL models are the complete enumeration of :

(a) the full logical structure of all the tables in your database, PLUS  

(b) a formal definition of all the constraints that govern this logical data structure.

"full logical structure" includes : name of the table, plus all the attribute definitions (name + data type).  

"all the constraints" includes : the key constraints on the tables, the foreign key constraints between tables, PLUS all the other business rules that do apply to the model, but do not fit the first two categories.

Logical models as per this definition are hardly ever spelled out anywhere, so I think I'm safe assuming that you are actually not really talking of LOGICAL models, but CONCEPTUAL models instead.

And there the answer is : include or exclude stuff depending on what exactly the message is that you want to convey to your audience. If that includes data types of the attributes, then include the data types. If it doesn't, leave them out. If a certain table has no role to play in the story you want to tell the audience, leave it out (and of course also its relationships). If relationship cardinalities are important in your story/for your audience, include them. Otherwise, leave them out. etc. etc. etc.
OP asked,

> 
> What are the core elements when it comes to present a data model?
>  (logical one)
> 
> 
> 

**What should be included in Logical Data Model**

Unlike a conceptual data model where you only talk about high-level data constructs, Logical data model (LDM) should include:

* Names of the `entities` (tables)
* `Attributes` (columns/fields) defined in those `entities` and
* `relationships` (or keys) among the `entities`.

The relationship should include the `cardinality` of the link; i.e., it should clearly specify `one-to-one`, `one-or-zero-ton-one`, `one-to-many` etc. relations between entities.

In addition, you need to ensure that you maintain the desired **normalization** level (2NF, 3NF, 4NF etc.) in the data model. The intended level of normalization will largely depend on the purpose of your data model (e.g. *OLTP* Vs *OLAP*). But whatever it is, your LDM should reflect it. 

Use business names for entities & attributes and ensure your model is independent of the technology platform.

> 
> What is not useful to mention?
> 
> 
> 

**What that need not be included in LDM**

Following things should not be included in LDM because PDM or Physical Data Model is a better place to specify these:

* Data-type constructs (e.g. platform specific constructs such as, *nvarchar*, *varchar2*)
* Indexes on the tables
* Details of partitions in the table
* Constraints (check constraints etc.)

Obviously there is no hard-and-fast rule, depending on situations you may need to tweak them as necessary.