典藏是介于编目和流通之间的一个业务环节。
一些大图书馆有专门的典藏部，一些小图书馆则将典藏业务纳入采编或者流通管理。目前dp2编目系统暂将这部分功能纳入编目界面处理。
下图显示了典藏核心业务“册登录” 的情景。
这个界面是针对业务流程设计的。
上方的“种检索词”输入域，最常见的是用来接纳条码阅读器输入的ISBN，软件具有自动适应条码阅读器的功能，能够识别和自动转换物码形态的ISBN。
ISBN输入后，软件立即自动从数据库中装载“种记录”，也就是图书的MARC记录，然后将窗口输入焦点自动切换到下方“册条码”输入域，等待工作人员扫入图书上已经贴好册条码字符串。
每扫入一个册条码字符串，软件自动向中部加入新创建的册信息。当一种图书的所有册都扫入后，工作人员只要紧接着扫描下一种图书的ISBN条码，软件会识别出来，自动保存上一条种和相关册记录，并装入刚扫入的新种的信息，等待工作人员继续输入新种的册条码。
在不断扫入册条码的过程中，工作人员有时难免会出错，比方说扫入重复的册条码；或者在种之间搞混了册条码，把已经登录到其它种的册再次登入。凡此种种，通过软件的册条码自动查重机制，都能够发现和警告，避免出现数据录入错误。
===
值得一提的是，dp2编目系统采用了种、册信息分开存放的数据结构。每个书目库（代表“种”）都具备一个配套的“实体库”，专门用来存储册信息。
这种结构的好处，是在流通业务中，只对实体库进行写入、修改数据操作，而不必对书目库进行写操作，这样系统在权限控制，负载平衡方面更科学、合理。而反过来，在编目业务中，则不必具备对实体库的写操作权限。
这样，虽然表面上是同一个编目界面来实现了编目部和典藏部两种不同的业务操作，但通过帐户权限的不同划分，两种业务就井然有序地区别开来。这也是一个通用的特征：Client/Server系统的权限验证应当在服务器端进行，而不取决于前端界面。
===
下面实例了一条册记录：
<?xml version="1.0" encoding="utf-8"?>
<root dprms:path="http://test/rmsws/rmsws.asmx?中文图书实体/2" dprms:timestamp="20a728bde316c8080000000000000010" xmlns:dprms="http://dp2003.com/dprms">
<parent>1</parent>
<barcode>0000002</barcode>
<state>
</state>
<location>流通库</location>
<price>
</price>
<comment>
</comment>
<borrower>R0000001</borrower>
<borrowdate>Fri, 10 Mar 2006 12:43:42 GMT</borrowdate>
<returndate>
</returndate>
<borrowDate>Fri, 28 Apr 2006 03:05:30 GMT</borrowDate>
<borrowPeriod>30day</borrowPeriod>
<no>0</no>
<renewComment>
</renewComment>
<reservations>
</reservations>
</root>
这显然是一条XML格式的记录。
<parent>元素表明，这条记录从属于相关联的书目库中id为1的书目记录。这是一种单链关系：只要册记录表明自己属于一条种记录，那就足够了，不需要从种记录设置指向册记录的信息。这种结构的好处，是增删册记录的时候，不必锁定和修改种记录，概念更简单。
<borrower>元素存储了借书者的证条码。
<reservations>元素用于存储本册图书的预约请求信息。
在体系结构上，dp2编目系统仅仅在书目数据有必要使用MARC格式的地方，使用MARC格式（当然这已经也是MARC格式的变体：MARCXML格式），而在其它任何数据格式方面，首选XML格式。