Application DB architecture

Today, the most common database architecture is the relational architecture. A relational database is constructed using a basic component called a table. A table is a two-dimensional structure that contains data arranged in rows and columns. A table contains a data set.

Rows contain data, the values of which, describe organizations, persons, activities, locations or things. Each row also contains data that uniquely identifies each row in the table. The identifier is used by the database management system (DBMS) to access (identify) a particular row or group of rows in a table.

There are two discipines and two languages used in the analysis and design of databases. One language set describes the logical business elements during the analysis (business) phase and one set describes the physical database elements during the design (technical) phase. The architect uses the language of the business to talk to the customer and uses the language of the DBMS when speaking to the database administrator (DBA).

• An entity is discovered during analysis and becomes a table during design.

• An attribute is discovered during analysis and becomes a field during design.

• An identifier is proposed during analysis and becomes a key during design.

The reason for two sets of language is that the language of analysis may be used to specify databases in architectures that don't have tables or fields. Also, if the architect/database analyst references design elements as tables, keys, and fields during the analysis phase, we are subconsciously making design decisions prematurely. This is particularly true of keys, since database design is identifying and assigning key. If keys are mentioned during analysis, they are always referred to as "candidate keys". They don't become keys until design.

Application databases have been around a long time in support of automated systems. The earliest ones were on 80-column punched cards. Over the years, these application databases have migrated from punched cards to magnetic tape, to disk packs and on to mass storage devices. New techniques were introduced and added to the database design knowledgebase during these migrations but much of today's design technique still has it's roots firmly embedded in these earlier technologies. Some of these techniques do more harm than good but remain in the literature and are still taught as gospel.