your spell structure should probably only contain data related to each spell, and not contain anything about whether a specific character is allowed to use the spell, because that would be high maintenance, and lower the potential for modularity. to control which spells a character can use, you should use an array of spell names in your base character, which can be loaded from a separate data table.
so a generic character is given the name Merlin. using that name, it looks up a data table called CharacterSpellsTable, where each row has an array of names, and it copies this array into the character’s AvailableSpells. when you use a spell, you get a name from the AvailableSpells, and use it to look up spell data in a separate SpellsTable.
spell data only describes the statistics of a spell.
“who owns which spells” is a separate concept, which is not part of spell data, but instead part of character data or inventory data.
ideally, ownership should be editable at runtime, so designers can add any spell to any character, in game.
if you want to create a new character, which uses only existing spells, it should not require editing the spells data table. if you want to create a new spell, it should not require knowing which characters can exist.
the idea is, that programmers should give designers as much freedom as possible for mixing and matching any character with any spell, and the designers should be the ones who limit the player with rules. if you hard coded which characters are allowed to have which set of spells, you would run into trouble if a designer wanted to make a game mode where everyone gets the same set of spells, or the set of spells changes throughout the game, like Gun Game in Call of Duty.
so programmers should make things generic and flexible, while designers make things specific and challenging. programmers create as many new possibilities as they can, while designers limit these possibilities to create challenges and improve balance.