这里有一个前提，就是非专业开发人员，我仅仅想聊聊针对日常办公的人员，为了能在办公实战中发挥Access作用，需要学些啥。
有一种特殊的应用场景，是说只想用Access来存储数据，因为它存的数据很规范，那么主要使用Access的表和最简单的窗体就可以了，甚至边表关系都不需要建立。这种场景下，不需要特别学习，会设计表就行了，窗体一键创建，几分钟就搞定了。
更多的场景是贯穿从获取数据到输入报表的全过程（就像下图所示），这就要考虑学些什么了。
我画的这张表或许对初学者很有帮助，了解了Access的整个内容结构，至少你知道每个模块能做什么。事实上学习Access也是围绕上述这些模块来展开的。
首先表设计（包含表关系）无论如何要学好，然而不幸的是，表设计操作容易，思路却比较难，但它是根基，特别特别重要。结构清晰的表设计会给以后模块的设计和操作带来很多便捷。说它的思路难，主要是初学者的确难快速准确地知道怎样的表就是合理的了，需要你对查询、窗体报表、VBA基本能运行自如时，回过头来重新思考表如何合理地设计。总体意思就是，表设计容易、设计好了难，难是相对的，如果从头到尾做过几个Access应用，慢慢也就能感觉到怎样的表设计是合理的了。
接下来说查询，这个名称很容易让初学者产生误解。说白了，查询就是SQL语句，它在Access保存的就是那行SQL语句，不占用空间，设计原则就是，能在查询中实现的，就不要在表中实现（主要是说表中的计算字段）。微软的查询视图真是伟大的发明，把枯燥的SQL语句用可视化界面来做，用上几次就能得心应手，感觉很好。查询是在表基础上设计的，那么了解SQL语句就必不可少了，所幸它还算容易。总结起来，表和查询都是将来的数据源，名称有唯一性要求，这就是表和查询不能重名的原因。
再者就是窗体（含控件），作为与使用人重要交互界面，设计起来不难，也是最具趣味性的地方了。Access给我们提供了专门针对数据的窗体，难点在于属性（事件、方法）过多，除了可视化属性窗口中的，还有一些隐藏的属性，对于数据操作而言，隐藏的属性还很重要，要掌握，一定要掌握。难度嘛，关键在于理解，这些属性的原理明白了，写代码也许就是一种乐趣了。对于一般的办公应用，重点是掌握窗体（控件）与数据相关的属性（事件、方法），而且需要了解一些背后原理。比如窗体的Recordset和RecordsetClone属性，都能直接获取窗体的记录集，到底该用哪个呢？
对于报表，很纠结。不是说它难，是它的设计界面会吓退很多人，我一直没找到如何将界面放大缩小的功能（有知道的麻烦知一下，不胜感激），加上眼神也不好，唉，不想提了。我们一般都喜欢把报表做成表格，这就给报表设计增加了难度。在报表设计上我花了大量的时间，测试了各种方法，挖掘操作方法和快捷键，同时也总结了大量经验和技巧，旨在了解它的各种特性，能快速进行设计，将来可以做成教程，让更多的人不再为设计而发愁。不过对于有固定格式的报表（比如员工档案表）设计者而言，有个极好的消息，就是使用模板。用Word或Excel把报表画好，在Access中调用后将数据写入其中就OK了，这些代码你可以重复使用，复制粘贴加修改就好。当然如果你代码能力不错，也可以用Access去操控Word或Excel中设计的表格样式。
最后说说宏和VBA，对于宏，尽管不是这样子的，你也可以把它理解为它是可视化的部分VBA代码，大部分宏运行时，实际是在执行DoCmd命令。因为绝大部分宏命令，你都可以找到相对应的DoCmd对象方法。这实际上给我们提供了一个便利，如果你不知道DoCmd方法的参数怎么写，你可以在宏中设计好再转换为VBA代码，就一目了然了。了解和学习宏或VBA我认为是必然的（宏简单快捷、VBA更自由），除非你的应用特别简单，不然你会发现你的应用，功能会大打折扣。
对于办公人员，解决问题是关键，所以学习Access本身自有的功能就完全够了，实用就好，有兴趣再扩展学。顺带提一句，Access的集合概念简直是它的灵魂级范畴，等你学到代码的阶段你就会明白了。
下次再谈Access学习方法。