When programming an OO program using a SQL database back-end, do objects' attributes correspond with the rows in the tables? Or more than that? I don't quite understand how objects' attributes relate to data in tables. Thanks for your help.
It really depends which orm you are using, however, in general the idea is:
class = > table
instance => row
attribute => column
You need to be more specific, and possibly do a little bit of research on what is available on your selected platform. While there are ways of mapping various Object Oriented languages onto databases, there is no "one-size fits all" approach.
ennuikiller mentioned some things, but an object may also be store over multiple rows and tables because there may be no correlation because of how data is modelled and normalised.
It's not straightforward... some reading Object-relational impedance mismatch (Wikipedia)
Read a little about Object-relational_mapping
a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.
For Java
or .NET
, the hibernate project provides relational persistence.
Hibernate is a powerful, high performance object/relational persistence and query service. Hibernate lets you develop persistent classes following object-oriented idiom - including association, inheritance, polymorphism, composition, and collections. Hibernate allows you to express queries in its own portable SQL extension (HQL), as well as in native SQL, or with an object-oriented Criteria and Example API.
Unlike many other persistence solutions, Hibernate does not hide the power of SQL from you and guarantees that your investment in relational technology and knowledge is as valid as always.
My answer is no.
The goal of OO design is to optimize for the ease of specifying program behavior. The goal of database design is to optimise for ease of data storage/retrieval. These goals are very different and can and will lead to very different decompositions of the problem domain.
It's possible to map one to the other, but then you will encounter the impedence mismatch, as others have mentioned, which is basically the technical consequence of the different goals of the two models.
Jorg mentioned the "Vietnam of computer science" article in the comments, which is worth a read. You can skip the historical stuff on Vietnam, if you're short on time.