Identifying an organization's business objects is typically the first order of business during Requirements Analysis.
Since most database design situations involve businesses that already have some sort of database in place, the first place to look for business objects is in the existing database, whether
legacy[1],
paper-based[2], or both.
Business objects are things (both tangible and intangible) in a business environment that are
related, and about which data is (or needs to be) stored. For Employees, projects, customers, appointments, students, products, orders, suppliers, all of these are
objects about which organizations store information. During Requirements Analysis, business objects must be identified and sorted according to subject. If two or more distinct subject categories appear, a database should be created for each.
Remember, multiple databases can be handled by a single RDBMS, and queries and user views (such as stored queries) can be created across databases. It makes no sense to have a database deal with more than one subject category. Keep in mind that every organization makes decisions about which business objects it will and will not store data about. For example, in the fictional Stories on CD, Inc. case study with which you will work throughout this course, Ted and Lisa have decided that they do not want to have any data about themselves (as owners/employees) stored on the company database.
Business objects are converted into
entities[3] in the logical-design stage.
Entities, in turn, are ultimately translated into database tables with
SQL[4],
the industry-standard database programming language. The next lesson describes the characteristics of business objects.
[4] SQL: SQL is an acronym for Structured Query Language. It provides a set of commands that can be used to add data to a database, retrieve that data, and update it. SQL, often pronounced “sequel”, is universally supported by relational database vendors.