CSDL 定义了EDM或者说是整个程序的灵魂部分 – 概念模型。当 前流行的软件设计方法通常都是由设计其概念模型起步。说概念模型可能比较抽象一个更容易接受的名字就是实体类。实体类是面向对象设计中一个最根本的组成部分，其体现了现实世界中对象作为一种计算中可以表示的对象设计方法。而EDM的CSDL就是要达到这样一个目的。这个在下文介绍Entity Framework优点时另有说明。

这个文件完全以程序语言的角度来定义模型的概念。即其中定义的实体、主键、属性、关联等都是对应于.NET Framework中的类型。下面xml element 来自作业提交系统（有删节）：

这部分XML文档，Schema是CSDL的根元素，其中定义的Namespace是用于ObjectCont ext与Entity Class的命名空间，Alias别名为此命名空间Namespace指定一个易记的名称，在定义Alias之后，在此Schema内的Element均可以该Alias作为Namespace的别名。Alias的使用可以参考如下xml element:

<FunctionImport Name="GETHOUSEWORKDONE" EntitySet="UpAssignments"
ReturnType="Collection(Self.UpAssignments)">

在这个根元素的内部的文档结构第一部分 – 实体容器大致如下：

<EntityContainer />
<FunctionImport />
<EntitySet />
<AssociationSet />
</EntityContainer>

下面的表格说明了这些节点及其属性的作用

可以看出，Entity 与Assciation 都被分开定义与两个部分，这样设计是出于当有多个EntityContainer 时， 其中的EntitySet 或AssociationSet 可以共享Entity 或Association 的定义。

接下来看一下CSDL 中最后一部分，Entity 与Association 的定义。

首先是Entity：

下表说明了其属性及其子节点与子节点的属性的含义：

最后Association 节，这是真正定义关系的地方。首先看示例：

这一节符合以下结构：

属性及其子元素属性的说明：

另外上面示例未涉及的概念，如下：

视图

在EDM设计器中添加视图基本与添加实体表一致，所生成的xml自行对照。某些环境下可能无法添加视图，原因未知，另外对于没有主键的表目前版本EntityFramework 支持不好，在设计器中无法添加，及时通过手工编辑xml的方式强行添加，在使用过程中也会出现问题。

ComplexType（复杂类型）

按MSDN中的例子，先描述如下场景。在一个销售系统中我们需要在一个订单中包含一个描述客户地址的实体，而这个实体又能良好的与存储模型映射起来，由于数据库不支持地址这种类型，所以我们可以将地址的每个字段与数据库相映射。且在概念模型中，及在C#代码可以控制的范围内，地址仍然作为一个独立的类型存在。由于EDM设计器不支持以可视化方式创建Complex Type，我们需要手动编辑CSDL与MSL来完成复杂类型的创建与映射。这部分示例将在介绍MSL后给出。