Design pattern for extracting classes out of data streamed from Excel Rows/Cells, when the data will not always have the same 'shape'/contents?

I'm designing a system that will take in data from spreadsheets, iterate over the data in the spreadsheet, and create business model objects depending on the type of data that is processed to pass further along in the service and carry out additional operations.

However, the spreadsheet data is not always the same - for instance, a user could be uploading a spreadsheet containing Car data, another spreadsheet containing Animal data, and another spreadsheet containing Food data.

As you might expect, these objects (Car, Animal, and Food) may share a few common attributes, but not all of them. Additionally, more spreadsheets may need to be updated in the future, so perhaps a user will be able to upload spreadsheets with Laptop data down the road. In this hypothetical example, we would be able to determine the type of "object" that is being imported in relatively quickly based on the values of the cells (we may even end up having it based off of file name or something similar)

switch(cell.Value[0]) {
   case(cell.Value[0] == 'CarVinNumber') {
      Car car = new car();
   } case (cell.Value[0] == 'AnimalSpecies') {
      Animal animal = new Animal();
    }
    ...
    ...

and so on.. this would obviously become a complicated logic, and we'd be branching off future processing steps based on whichever case is triggered.

It seems like the Strategy pattern comes close, but from my understanding it relies on the concrete implementations sharing a base parent class, which is not the case here.

Is there a design pattern that could help make the assignment of these objects remain generic? Ideally, I'd like to avoid having to write a block of code similar to: