Creating a struct-of-arrays database with encapsulating interface c++
There is a lot missing from this question, but there is enough code to be able to tell that a lot that could be improved.  Here are some ideas for improving your code.
Use all of the required #includes
All of the #includes for this code are missing in the description.  I believe the required list is this:
#include &lt;complex&gt;
#include &lt;cstdint&gt;
#include &lt;memory&gt;
#include &lt;vector&gt;

Provide complete code to reviewers
This is not so much a change to the code as a change in how you present it to other people.  Without the full context of the code and an example of how to use it, it takes more effort for other people to understand your code.  This affects not only code reviews, but also maintenance of the code in the future, by you or by others.  One good way to address that is by the use of comments.  Another good technique is to include test code showing how your code is intended to be used.  There is a bit of that in your question, so we'll start from there.
Start with the desired interface
It's usually very useful to start by imagining how we'd like to use the code before implementing the interface.  It appears that there exists some external source of orbital data (I'm guessing TLE) which this code is supposed to read and parse (not shown) and then provide storage and access methods.  First, rather than two separate classes, OrbitalDataBase and OrbitalAccessor, it seems clear to me that there should rather be a single OrbitalDataBase and that the accessor should be a member function.  That leads to the first simplification:
std::complex&lt;double&gt; coef(uint32_t ith_orbital, uint32_t i) const {
    return m_orbital_coefs[ith_orbital * nbas * number_of_lm_pairs_per_orbital[ith_orbital] + i];
}

Don't write this-&gt;
Within member functions this-&gt; is redundant. It adds visual clutter and does not usually aid in understanding.
Use more whitespace for clarity
It's very difficult to parse the OrbitalDataBase constructor because it's all run together with very little whitespace.  I'd modify it to look more like this:
struct OrbitalDataBase {
  OrbitalDataBase(std::shared_ptr&lt;FEMDVR&gt; a_radial_grid, std::shared_ptr&lt;AngularGrid&gt; a_angular_grid)
      : nbas(a_radial_grid-&gt;getNbas())
      , number_of_lm_pairs_per_orbital()
      , m_orbital_coefs() 
{
    m_orbital_coefs.reserve(a_radial_grid-&gt;getNbas() * a_angular_grid-&gt;getNumChannels());
}

Don't explicitly invoke implied constructors
The constructor, reformatted as above, reveals that the default and implied constructors for number_of_lm_pairs_per_orbital and m_orbital_coefs are explicitly called.  This is both unnecessary and unhelpful.  Simply omit those two lines.
Prefer const references to smart pointers
If you are passing in data, such as the FEMDVR and AngularGrid in this code, that are used but not altered, this implies const.  Further, if we are not sharing ownership, which appears to be the case here, these should be references rather than std::shared_ptr.
OrbitalDataBase(const FEMDVR&amp; a_radial_grid, const AngularGrid&amp; a_angular_grid)
    : nbas(a_radial_grid.getNbas())
{
    m_orbital_coefs.reserve(nbas * a_angular_grid.getNumChannels());
}

Understand modern use of inline
Based on how you're using it, it appears that you are abusing the inline keyword to get an effect that the compiler is already going to provide without it.  That is the inline specifier for functions used to be a request to the compiler to optimize by putting the code inline rather than creating an explicit function call.  However, this was only ever a suggestion, and the changing semantics of inline for C++17 and beyond are likely to lead to trouble unless very carefully used.  The reason is that, starting with C++17, it tells the compiler that multiple defifinitions are allowed, but if they differ in any way, invoking the function is undefined behavior.  For these reasons, you're better off omitting inline in most cases.
Rethink your data structures
Right now getting a value back uses this rather complex form:
std::complex&lt;double&gt; coef(uint32_t ith_orbital, uint32_t i) const {
    return m_orbital_coefs[ith_orbital * nbas * number_of_lm_pairs_per_orbital[ith_orbital] + i];
}

This is very cache unfriendly because it has to look up one value from number_of_lm_pairs_per_orbital and then use that to index into another vector.  It may make things more clear and give better performance if instead you defined a struct or class that encapsulated both.  The obvious would be this:
struct Orbital {
    std::vector&lt;std::complex&lt;double&gt;&gt; m_orbital_coefs;
};

Then OrbitalDataBase could use std::vector&lt;Orbital&gt; as its only data member, since the number of coefficients is m_orbital_coefs.size() and nbas is now m_orbital_coefs.size().
Even simpler might be this:
using Orbital = std::vector&lt;std::complex&lt;double&gt;&gt;;