You're asking in the wrong forum; this belongs in "Programming". But a brief overview...
An ORM is an "Object Relational Manager". Think of it is a translation layer between data as it is used in your program/application and data as it is stored in a relational database (such as MySQL).
When you're working with data in many (perhaps most) of the sorts of applications people use everyday, you're working with things that are best handled as big chunks that represent the whole idea of something. "Objects" in a program are representations of objects or entities in the world. (Roughly speaking, of course.) You could work with a long list of names and a long list of addresses and a long list of genders and a long list of hobbies and so on and so on, but it's a whole lot easier to manage profiles if you have a long list of Person objects, each of which has a name, an address, a gender, some hobbies, and so forth. It doesn't matter whether you're creating that profile or checking out a profile that's been returned from a search, working with a representation of a Person is natural and easy to understand.
But "objects" are lousy ways to store data in a way that's easy to search and analyze. So we pull the data apart and store it in a way that makes the most sense for those tasks, and if necessary, we re-create the object once we've found what we're looking for. And the version of the object may be different at different times. If you're looking at a Person object in terms of an internet dating match-up, you're looking at different things than when you look at the same database for billing the user. You really don't care that the guy has blue eyes and claims to love opera, you want to know that he's two weeks overdue paying his membership fee—but you do want to be looking at the "same" person all of the time, even if the subset of the data you're interested in is not the same. When the guy who doesn't pay his bills gets suspended, then the blue-eyed opera lover stops showing up in other people's searches.
On ORM is a part of an application framework that's supposed to automagically handle the translation between the objects your application works with and the nice, neat, searchable data in the database. And it does, provided that your app sticks to the script and doesn't do anything surprising. But like all automagic programming aids, when it stops being a help, it can be a real hindrance. Add a little something that the framework designer didn't plan for, and you pretty much have to throw out the framework ORM and write your own translation layer. (Arguably, you should have done that in the first place. I haven't seen very many framework projects that didn't eventually go well over time and over budget because the framework got in the way.)