The (very small piece of) good news: Ejecting the disc early did not cause your problems. Don't beat yourself up over that.
The rest is bad news, I'm afraid. Your hard disk is, in technical terms, a complete and utter mess. :-(
Your /dev/sda1, /dev/sda2, and /dev/sda4 are all of type 0x42. This type is also identified as "SFS" by fdisk, although that acronym actually refers to a use that's no longer common -- it's really a Windows 2000 (and later) dynamic disk (aka logical disk manager, or LDM), which is similar to (but incompatible with) the Linux logical volume manager (LVM).
In any event, my guess is that you started with an LDM configuration in Windows, but either you or the Ubuntu installer didn't correctly identify it as such. Instead, either you or the Ubuntu installer tried to resize the LDM partitions as if they were plain filesystems to make room for Ubuntu. This was a BIG mistake, because it damaged the LDM setup and may have damaged the filesystems contained within it. This resulted in a trashed Windows installation. What's more, your hopes of a full recovery are slim (but not nonexistent).
As a first step, I suggest you back up all your data files that you can actually read. Do this from Linux and/or Windows emergency tools. If you can't find all your files, do a low-level backup of your entire hard disk to another one, as in:
sudo dd if=/dev/sda of=/path/to/big/space/backup.img
You'll obviously need a big disk to hold the backup; in this example it's mounted at /path/to/big/space. If an attempted repair makes matters worse (and there's a double-digit probability that it will), you'll be able to restore things to the current state from the backup.
Once you've got backups, I recommend you boot an emergency disk and delete all your partitions. You can then use TestDisk to try to recover your original NTFS volumes. You may need to fiddle with TestDisk options to get it to recover the right filesystems; do not let it recover any Linux filesystem, since the Linux filesystem may well be overwriting critical NTFS data, and it's the NTFS data you need to recover. This process is unlikely to work completely, but there's a chance that you'll be able to recover at least one filesystem. It may be damaged, though, in which case you'll have to recover it from Windows. Even if you get back a filesystem, some files may be corrupt or lost.
If this process fails, your last-resort recovery effort (assuming you don't have existing backups) is to use PhotoRec or some similar tool to do a file-level recovery. The last I checked, PhotoRec didn't do a good job of recovering filenames, so you'll have to sift through files individually to figure out what they are. This will be tedious. I've seen claims that there are commercial Windows tools that do a better job of recovering filenames from NTFS volumes, so you may want to look into such options instead of PhotoRec. I don't know much about these alternatives, though, so I can't recommend a specific product. You might want to ask about this on a Windows forum.
As a side note, Windows creates LDM configurations without warning when you create more than four partitions on a disk. If your disk had over four "partitions" (really logical volumes) when you started, it had LDM to begin with. If you created new partitions for Linux by using a Windows tool, though, that triggered this whole chain of events. Rule #1 when preparing to install Linux on a system that uses Windows is to not use Windows tools to create Linux partitions. You can use the Windows tools to shrink the Windows partition, but leave that free space unallocated; let the Linux installer create its own partitions in the unallocated space.
EDIT: I just noticed that your fdisk and lsblk outputs are inconsistent about what's what; fdisk suggests that Linux is installed to /dev/sda3, but lsblk suggests it's installed to /dev/sda2. I wrote the above based largely on the fdisk output, but lsblk is probably more trustworthy. Nonetheless, the broad strokes of what I wrote probably still apply.
