モンスターのデータ構造を、DBのテーブルみたく、ある程度、形にできました
マスターと、それらを参照するテーブルの構造を作っていきました

マスター

・モンスター
・属性
・タイプ
・ドロップ
・覚醒スキル
・スキル
・リーダースキル
・進化
と、このぐらいでてきました、モンスターを扱うだけなら、こんなものでしょう

その他参照するやつ

・モンスタータイプ
・モンスター覚醒スキル
・モンスター超覚醒スキル
・スキルエフェクト（効果）
・リーダースキルステータス
・リーダースキルアクション
・進化素材
ざっと、こんな感じでしょうか
モンスターのタイプ・覚醒スキル・超覚醒スキルは、1モンスターに対して複数持つので、よくある形になりますが、スキル・リーダースキルの持ち方が、少し工夫が必要でした。
ちょっと伝えづらいので、画像にしてみました
スキルの持ち方

1スキルに対して、複数モンスターがいて、1スキルに対して、効果が複数あります。スキルは割とシンプル。で、今思えば、スキルの処理順も入れたほうがいいですね、スキルと効果の間に、中間テーブルを挟もうかどうか、うーんめんどうですが、ここは後に響きそうなので、考えます。
リーダースキルの持ち方

1リーダースキルに対して、複数モンスターがいて、1リーダースキルに対して、複数アクションがいて、それぞれにステータスの増減のデータを持たせている形です、
やはりすこし、ややこしくなってしまいました。
まず、1つのリーダースキルに1つしかデータを持たないものは直で持たせています、自動回復倍率とか、火属性軽減とか、です。
で、ステータス上昇系は、属性とかタイプ指定のものもあるため、別で管理しています、それが、リーダースキルステータスになります。
で、一番重要な、「なんかしたとき、なんかが変わる」のデータを持つのが、リーダースキルアクション、です。
リーダースキルアクションは複数の様々なアクションを持たせるために、データ構造を分けています。たとえば、闇セイバーは、HP○%以下で強くなるし、何色か消しても、強くなります、これがいわゆる、「なんかしたとき」にあたります。
「なんかが変わる」の部分はアクション全てにリーダースキルステータスを持たせることで、解決しました。

実際に検索する時のはなし

データの持ち方はできましたが、これ、検索する時、SQL大丈夫かという話
特にスキル、リーダースキルで、実際に使われそうなSQLを考えて、どんな感じになるのか、実装前にやっておいたほうが良さそうだと思いました。
テーブル名、カラム名は適当に命名してます

スキルで、全体攻撃を3ターン以上、火から水へ変換する、スキル自体の最大ターンが10以下のモンスターを検索する時

SELECT m.* FROM monsters AS m
LEFT JOIN skills AS s ON s.id = m.skill_id
JOIN skill_all_attacks AS a_a ON a_a.skill_id = s.id
JOIN skill_drop_convs AS d_c ON d_c.skill_id = s.id
WHERE
  a_a.turn >= 3　AND
  d_c.from_drop_id = 1 AND d_c.to_drop_id = 2 AND
  s.max_turn <= 10

多分、スキルは大丈夫そう。そこまで複雑でもない
難関のリーダースキルの検索を試します
火属性のHPと攻撃力が2倍以上で、操作時間1秒以上延長、HP50%以下で悪魔タイプの攻撃力が5倍以上になり、7コンボ以上で攻撃力が3倍以上になり、固定1ダメージ以上を与えるモンスターを検索する時

SELECT m.* FROM monsters AS m
LEFT JOIN leader_skill AS l_s ON l_s.id = m.leader_skill_id
JOIN l_skill_statuses AS ls_s ON ls_s.id = l_s.l_skill_status_id
JOIN l_skill_action_hp_conditions AS h_c ON h_c.leader_skill_id = l_s.id
JOIN l_skill_statuses AS s_h_c ON s_h_c.id = h_c.l_skill_status_id
JOIN l_skill_action_combos AS l_c ON l_c.leader_skill_id = l_s.id
JOIN l_skill_statuses AS s_c ON s_c.id = l_c.l_skill_status_id
WHERE
  ls_s.is_fire = true AND
  ls_s.hp_rate >= 2.0 AND
  ls_s.atk_rate >= 2.0 AND
  l_s.ext_ope_time >= 1 AND
  h_c.less_than >= 0.5 AND s_h_c.atk_rate >= 5.0 AND s_h_c.is_demon = true
  l_c.combo >= 7 AND s_c.atk_rate >= 3.0 AND s_c.fixed_damage >= 1

きつそう。書いてても意味分からなくなって、ちゃんと通るのかもわからない
1つのアクションを検索するのに2つJOINしなきゃならないのが微妙で、これは、リーダースキルステータス不要説？がでてきました
リーダースキルステータすにカラム追加とか、改修時に全アクションを変更するという影響を及ぼしてしまいますが、SQLが複雑になるよりマシかなと思いますがどうでしょう、検討です

ちょっと課題が出てしまいましたが、いいかんじになりましたら、
実際にrailsでマイグレーションして、テーブル作ってこうと思います