NDS对于导航引擎而言，只是一个冷冰冰的数据库，如何从这个数据库中获取导航自己适用的数据哪？
这部分就是地图与导航软件的交互接口。如何设计一个高效、易用的地图接口？
品质需求分析
1. 对外交互的系统模块上层模块：导航的数据驱动模块DataAccess，利用本模块获取数据；
下层模块：地图数据及数据库的API
这个模块的设计还是有一些可变性的，主要原因是在于地图数据种类或格式的新增或变化，导航使用的数据结构的格式和种类变化。
这个可以分为两个部分：一部分是不易变化的，如导航的基本数据，坐标，各种系统参数；另外一部分就是易变数据，跟导航数据的更新比较密切的，如POI，Guidance等。
总而言之，这部分的可变性是根据上层数据的需求而变化。
这个模块对性能的要求是杠杠的，而关键部分是如何使用地图接口，数据解析转换，数据传递方式。
根据功能要求和信息隐藏原则，对本部分进行模块细化设计。便于复用。
本模块需要sqlite库的支持，并且与nds数据库的版本相匹配。
另外，需要注意本机上其他程序可能在使用sqlite的其他版本。
如何安全的使用地图API？
如何让其他模块安全的使用本模块的API？（防御性编程）
功能需求分析
1. 提取。本模块首先需要从数据库中提取数据。这个层面是直接使用sqlite从数据库中获取数据，这部分又称为SAL模块。
2. 解析。将NDS数据块转换为对应的类对象或数据结构中，这部分被称为OPAL(object parser libary)模块。
3. 接口。DA抽象了一些accesssor接口，而真正实现这些简单易用的对外接口是NDS，供导航引擎使用。
以上分析只是其中一种方案，还有一种方式是，将读取和解析放在一起完成，以提高性能（具体提高多少，未测试）。
详细设计
1. 数据库接口封装层SAL:对sqlite接口的一些简单封装：
SqlConfiguration配置
sqlconnection
对sql query的封装：
查询接口的抽象BasicQuery：一般的查询是传入查询参数列表，或者直接执行sql语句。
这个抽象，能被很多结构复用，如filteredPoiQuery, landmarkiconpositionquery, namedobjectquery, poicategorysearchquery,poidetailsquery, poiinregionquery,rangequery, tile等。
定义sqlite与nds相配套的一些数据结构，如bind、parameter、blob、column、singleId/Name、updateRegion、version等。
2. 解析层
这部分会直接调用SAC层的接口，SAC尽量不涉及具体的业务逻辑，只是对数据库接口的抽象封装，本部分是将参数传入SAC层中，并将结果转换为DA中容器对象中。
这部分会与DA中的数据结构紧密相连，其将查询到的数据直接放入已分配好的DA container中。
3. provider的设计。
provider有两个职责：
一个是初始化数据库，执行数据库的open, close操作
另一个就响应DA中Hub的请求，条用解析层中的接口，抽取地图数据，并转化为DA中的数据结构，即创建DA中的container。
这里可以分为两部分，一部分是DA中的provider接口，供Hub使用，另外一部分是ndsProvider的实现，二者分离开来，做到尽量解耦。
4. accesor使用接口设计
accessor是抽象出的对外公共接口，用于上层应用与底部数据解析的解耦。（直接使用解析模块获取地图数据，技术上是可行的，但一般不这么做）
accessor可抽象出以下一些接口：
basicmap
naming
routing
positioning
terrain
...
由以上接口可以看出，大部分接口是与nds的building block紧密相连的。
附上nds的主要的building block的类型和分类：
最后，由以上描述，可以自然的得到NDS地图底层接口的依赖关系: