From everything in this thread, it sounds like you have the outline of your application and the beginning of your DB already set. With that in mind.
I agree that DB first is viable. I would add, what are your strengths Criss? If you are more experienced with development than database design, then it would be a good idea to at least flesh out your application. Classes, libraries, basic flows and handoffs. That way you can think of your database design more along the lines of "what does my app need to get/to send at this point." It may help you see what is best for your data and business processes.
To look at the question you asked:
You have a Bellies table with Bellies_ID, and the pertinent information about that particular sow. You could create that Events table, but as you noted you will end up with a huge table with the potential for a lot of Null values. One of my concerns is how many concurrent users do you have? Because having only 1 table for all events will create locks and potential conflicts if multiple writes are coming in.
So, that leads us to either a table per event, or is there a way to combine insemination + births? Something to think about. Let's assume 3 tables: insemination, births, weaning.
For each you have an FK linking back to your Bellies table.
There is a ID each for insemination, births, weaning. What that is based on depends on what is in each table. For example, Insemination seems straightforward: Insemination_ID, FK Bellies_ID, date, sperm source....etc.
From my perspective you can use the Bellies FK to relate the tables, with each Bellies_ID relating to multiple records in the event tables. It may not be fully normalized, but it is easy to understand, create and maintain.