원문은 위에서 참고.
아래는 간단하게 위의 내용을 요약한 것을 쓴다.
System DBA
A system DBA focuses on technical rather than business issues, primarily in the system administration area. Typical tasks center on the physical installation and performance of the DBMS software and can include the following:
* Installing new DBMS versions and applying maintenance fixes supplied by the DBMS vendor
* Setting and tuning system parameters
* Tuning the operating system, network, and transaction processors to work with the DBMS
* Ensuring appropriate storage for the DBMS
* Enabling the DBMS to work with storage devices and storage management software
* Interfacing with any other technologies required by database applications
* Installing third-party DBA tools
System DBAs are rarely involved with actual implementation of databases and applications. They might get involved in application tuning when operating system parameters or complex DBMS parameters need to be altered.
Indeed, the job of system DBA usually exists only if the organization does not have an official system administration or systems programming department.
1. System DBA
system DBA는 비지니스 이슈보단 테크니컬한 부분에 포커스가 있는데 특히 시스템 관리 부문쪽이다.
물리적인 설치와 DBMS의 성능향상을 위한 업무 이외에도 다음을 포함한다.
- DBMS의 설치와 DBMS의 벤더에서 제공하는 패치나 fix들을 설치하여 유지한다.
- 시스템 파라미터 들을 설정하고 조절한다.
- DBMS와 더불어 OS, network, transaction 프로세서들과의 진행을 위한 튜닝을 한다.
- DBMS를 위한 적절한 스토리지를 구성한다.
- DBMS가 스토리지 디바이스와 관리 소프트웨어들과 같이 협력할 수 있게 설정한다.
- DB의 app들에 의한 다른 기술들과 접목시킨다.
- 3rd party DBA 툴을 설치한다.
Database Architect
Some organizations create a separate position, database architect, for design and implementation of new databases. The database architect is involved in new design and development work only; he is not involved in maintenance, administration, or tuning of established databases and applications. The database architect designs new databases for new or existing applications.
The rationale for creating a separate position is that the skills required for designing new databases are different from the skills required to keep an existing database implementation up and running. A database architect is more likely than a general-purpose DBA to have data administration and modeling expertise.
Typical tasks performed by the database architect include:
- Creating a logical data model (if no DA or data modeler position exists)
- Translating logical data models into physical database designs
- Implementing efficient databases, including specifying physical characteristics, designing efficient indexes, and mapping database objects to physical storage devices
- Analyzing data access and modification requirements to ensure efficient SQL and optimal database design
- Creating backup and recovery strategies for new databases
2. Database Architect
어떤 조직들은 DB architect 라는 위치를 따로 만드는데, 이는 새로운 db를 디자인하거나 구현하기 위함이다.
db 아키텍트는 유지보수, 관리, 튜닝, db/app 생성 등의 업무가 아닌,
오직 db의 새로운 디자인과 개발에만 매달린다.
- 논리적인 data 모델을 만든다. (DA나 모델러 직업이 없을때)
- 논리적인 data 모델을 물리적인 디자인으로 변경
- 특정적인 물리 특징, 효율적인 인덱스 구조, db의 objects를 물리적인 스토리지 device에 사상하는 등의 기술등을 포함한 효율적인 db를 구현한다.
- data의 접근을 분석하고, 효과적인 SQL과 최적화된 DB의 디자인을 확실시 하게 하기 위한 요구에 대한 분석
- 새로운 db를 위해 백업과 복구 전략을 만든다.
Database Analyst
Another common staff position is the database analyst. There is really no set definition for this position. Sometimes junior DBAs are referred to as database analysts. Sometimes a database analyst performs a role similar to that of the database architect. Sometimes the data administrator is referred to as the database analyst or perhaps as the data analyst. And sometimes a database analyst is just another term used by some companies instead of database administrator.
3. DB Analyst
정확한 정의는 없다. 때때로 신입 DBA를 , 또는 db 아키텍트와 같은 롤을 하는 애들을 이렇게 부르기도 한다.
그리고, data 관리자를 db analyst 혹은 data analyst 라고 부른다. 다른 회사에서는 db 관리자를 이 용어로 부르기도 한다.
Data Modeler
A data modeler is usually responsible for a subset of the DA’s responsibilities. Data modeling tasks include the following:
- Collecting data requirements for development projects
- Analyzing the data requirements
- Designing project-based conceptual and logical data models
- Creating and updating a corporate data model
- Ensuring that the DBAs have a sound understanding of the data models
모델러는 DA가 하는일의 작은 부분이라 생각하면 된다.
- 프로젝트를 하기 위하여 데이터의 요구사항을 모은다.
- 데이터 요구사항을 분석한다.
- 프로젝트 기반의 개념과 논리적인 데이터 모델을 디자인한다.
- 통합된 데이터 모델을 만들고 업뎃 한다.
- DBA가 데이터모델에 대해서 이해할 만하게 한다.
Application DBA
In direct contrast to the system DBA is the application DBA. The
application DBA focuses on database design and the ongoing support and
administration of databases for a specific application or applications.
The application DBA is likely to be an expert at writing and debugging
complex SQL and understands the best ways to incorporate database
requests into application programs. The application DBA must also be
capable of performing database change management, performance tuning,
and most of the other roles of the DBA. The difference is the focus of
the application DBA—it is on a specific subset of applications rather
than the overall DBMS implementation and database environment.
Not every organization staffs application DBAs. However, when
application DBAs exist, general-purpose DBAs are still required to
support the overall database environment and infrastructure. When
application DBAs do not exist within an organization, general-purpose
DBAs are likely to be assigned to support specific applications while
also maintaining the organization’s database environment.
There are pros and cons to staffing application DBAs. The arguments in favor of application DBAs include the following:
- An application DBA can better focus on an individual application, which can result in better service to the developers of that application.
- The application DBA is more often viewed as an integral component of the development team and therefore is better informed about new development plans and changes.
- Because the application DBA works consistently on a specific set of applications, he can acquire a better overall understanding of how each application works, enabling him to better support the needs of the application developers.
- With a more comprehensive understanding of the application, an application DBA will have a better understanding of how the application impacts the overall business. This knowledge will likely result in the execution of DBA tasks to better support the organization.
But all is not favorable for application DBAs. There are cons to implementing an application DBA role:
- An application DBA can lose sight of the overall data needs of the organization because of his narrow focus on a single application.
- The application DBA can become isolated. Lack of communication with a centralized DBA group (if one exists) can result in diminished sharing of skills.
- When an application DBA implements useful procedures, it takes more effort to share these procedures with the other DBAs.
- Due to the application-centric nature of the position, an application DBA can lose sight of new features and functionality delivered by the DBMS group.
Task-oriented DBA
Larger organizations sometimes create very specialized DBAs that focus
on a specific DBA task. However, task-oriented DBAs are quite rare
outside of very large IT shops. One example of a task-oriented DBA is a
backup-and-recovery DBA who devotes his entire day to ensuring the
recoverability of the organization’s databases. Security, compliance
and data protection are other subjects that could be the focus of a
task-oriented DBA.
Most organizations cannot afford this level of specialization,
but when possible, task-oriented DBAs can ensure that very
knowledgeable specialists tackle very important DBA tasks.
Performance Analyst
Performance analysts are a specific type of task-oriented DBA. The
performance analyst, more common than other task-oriented DBAs, focuses
solely on the performance of database applications.
A performance analyst must understand the details and nuances of SQL coding for performance and be able to design databases for performance. A performance analyst will have very detailed technical knowledge of the DBMS so that he can make appropriate changes to DBMS and system parameters when required.
However, the performance
analyst should not be a system DBA. The performance analyst must be
able to speak to application developers in their language in order to
help them facilitate appropriate program changes for performance.
The performance analyst is usually one of the most skilled,
senior members of the DBA staff, a role that s/he has grown into due to
experience and the respect s/he has gained in past tuning endeavors.
Data Warehouse Administrator
Organizations that implement data warehouses for performing
in-depth data analysis often staff DBAs specifically to monitor and
support the data warehouse environment. Data warehouse administrators
must be capable DBAs, but with a thorough understanding of the
differences between a database that supports OLTP and a data warehouse.
Data warehouse administration requires experience with the following:
- Business intelligence, query, and reporting tools
- Database design for read-only access
- Data warehousing design issues such as star schema
- Data warehousing technologies such as OLAP (including ROLAP, MOLAP, and HOLAP)
- Data transformation and conversion
- Data quality issues
- Data formats for loading and unloading of data
- Middleware
