You use ADO.NET in .NET framework to access data stored in various database, including MS Access database (*.mdb/*.accdb). Note, it is not necessary to install MS Access itself, but you need to installed MS Access DB Engine (free download from MS site), if the computer does not have MS Access installed. However, since these days no one uses 32-bit AutoCAD, the MS Access db Engine must also be 64-bit. This may lead to problem: if the computer has MS Office suite, including MS Access, it is most likely 32-bit, then you cannot install 64-bit MS Access DB Engine. If the MS Office suite does not include MS Access, the 64-bit MS Access DB Engine can be installed if the MC Office is later version (at least Office 2013 or later). For earlier Office, installing 64-bit MS Access DB Engine could be very tricky, or not possible (when Office suite is too old, like 2005/2007). Also, the installation needs local admin privilege, this along makes thing unfavorable. Unless you have to use MS Access' UI to manage the data outside AutoCAD (especially you have already have MS Access application working on the data), choosing *.mdb/*.accdb to store data for AutoCAD's external data source is bad choice. Other choices of data storage include real database server (SqlServer/Express, MySql...), lightweight file-based Sql-lite, or even XML file. text file...
While you learn database programming with ADO.NET, you'd better off do it outside AutoCAD with an simple console EXE or Win Form EXE to save you from having to start time-consuming AutoCAD for debugging/testing. The data accessing code should be in a class library (DLL) project, referenced into the EXE; so later it can be referenced by your Acad add-in project to access data. There are huge amount of posts/sample code/tutorial video on ADO.NET online. Search the net and off you go.
If you do have experience/knowledge of data access programming, you might want to define a data access Interface, which sits between AutoCAD working code and real data source; so that AutoCAD only knows the interface and does not care where/how the data is stored (MS Access DB, SQLServer, or served from somewhere in the cloud), and you have different code to implement the interface according to the data storage/source. Not knowing your database programming knowledge level, I am not going to elaborate more.