Database system development lifecycles

Size: px

Start display at page:

Download "Database system development lifecycles"

Theodore Gaines
5 years ago
Views:

1 Database system development lifecycles 2009 Yunmook Nah Department of Electronics and Computer Engineering School of Computer Science & Engineering Dankook University

2 이석호 ä ± Á Ç ºÐ ¼ ¼³ è ± Çö î µ ½Ã ¹ ³ ¼± 요구조건분석단계 데이타및처리요구조건 개념적설계단계 DBMS 독립적개념스키마설계, 트랜잭션모델링 논리적설계단계목표 DBMS 에맞는스키마설계트랜잭션인터페이스설계 물리적설계단계목표 DBMS 에맞는물리적구조설계트랜잭션세부설계 구현단계목표 DBMS DDL 로스키마작성트랜잭션 ( 응용프로그램 ) 작성

3 Connolly

4 TPC benchmark TPC-C, TPC-D, TPC-W tps (transaction/second) $/ tps 예 : Oracle 1 cpu 당 $50,000, 100 tps => 500 $/ tps

5 Simsion

6 이춘식

7 오세종

8 데이타베이스설계프로세스 [Nah] 요구사항분석 인터뷰, 설문조사, 작업관찰등 개념설계 E-R 모델링 논리설계 E-R 모델 -> 관계설계로변환 관계설계 -> 정규화 물리설계 저장구조, 저장공간, table space, extent, 적재율등결정 Clustering 기준열결정 Indexing 대상열결정 테이블분할여부결정 테이블저장위치, 중복필요성결정 ( 분산 DB)

9 Database Design Methodology [Connolly, Ch.15, pp ] Conceptual database design 1) identify entity types 2) identify relationship types 3) identify and associate attributes with entity or relationship types 4) determine attribute domains 5) determine candidate, primary, and alternate key attributes 6) consider use of enhanced modeling concepts (optional) 7) check model for redundancy 8) validate conceptual model against user transactions 9) review conceptual data model with user

10 Logical database design for the relational model 1) derive relations for logical data model 2) validate relations using normalization 3) validate relations against user transactions 4) check integrity constraints 5) review logical data model with user 6) merge logical data models into global model (optional) 7) check for future growth

11 Physical design for relational databases 1) translate logical data model for target DBMS 1) design base relations 2) design representation of derived data 3) design general constraints 2) design file organizations and indexes 1) analyze transactions 2) choose file organizations 3) choose indexes 4) estimate disk space requirements 3) design user views 4) design security mechanisms 5) consider the introduction of controlled redundancy 6) monitor and tune the operational system

12 Practical Database Design Methodology Chapter 12, Elmasri & Navathe, Fundamentals of Database Systems (4 th Ed.), Addison Wesley, 2003

13 Life Cycle The information system life cycle (macro life cycle) 1. Feasibility analysis 2. Requirements collection and analysis 3. Design 4. Implementation 5. Validation and acceptance testing 6. Deployment, operation and maintenance

14 The database application system life cycle (micro life cycle) 1. System definition 2. Database design 3. Database implementation 4. Loading or data conversion 5. Application conversion 6. Testing and validation 7. Operation 8. Monitoring and maintenance

15 Database design and implementation process (activities 2 and 3) Overall process Requirements collection and analysis Conceptual database design Choice of a DBMS Data model mapping (also called logical database design) Physical database design Database system implementation and tuning

16 FIGURE 12.1 Phases of database design and implementation for large databases.

17 Detail process Phase 1. Requirements collection and analysis The major application areas and user groups are identified Existing documentation concerning the application is studied and analyzed The current operating environment and planned use of the information is studied Written responses to sets of questions are sometimes collected from the potential database users or user groups These questions involve the user s priorities and the importance they place on various applications

18 Phase 2. Conceptual database design Produce a conceptual schema for the database that is independent of a specific DBMS Often use a high-level data model such as the ER or EER model Specify as many of the known database applications or transactions as possible

19 Approaches to conceptual schema design The centralized (or one-shot) schema design approach The requirements of the different applications and user groups are merged into a single set of requirements A single schema corresponding to the merged set of requirements is then designed The view integration approach The requirements are not merged A schema (or view) is designed for each user group or application based only on its own requirements These schemas are merged or integrated into a global conceptual schema for the entire database (view integration phase)

20 Strategies for schema design Top-down strategy Start with a schema containing high-level abstractions and then apply successive top-down refinements For example, we may specify a few high-level entity types and then, split them into lower-level entity types and relationships Bottom-up strategy Start with a schema containing basic abstractions and then combine or add to these abstractions For example, we may start with attributes and group these into entity types and relationships We may add new relationships among entity types as the design progresses

21 FIGURE 12.2 Examples of topdown refinement. (a) Generating a new entity type. (b) Decomposing an entity type into two entity types and a relationship type.

22 FIGURE 12.3 Examples of bottom-up refinement. (a) Discovering and adding new relationships. (b) Discovering a new category (union type) and relating it.

23 Inside-out strategy A special case of a bottom-up strategy, where attention is focused on a central set of concepts that are most evident Modeling then spreads outward by considering new concepts in the vicinity of existing ones We could specify a few clearly evident entity types in the schema and continue by adding other entity types and relationships that are related to each Mixed strategy The requirements are partitioned according to a top-down strategy, and part of the schema is designed for each partition according to a bottom-up strategy The various schema parts are then combined

24 Schema (view) integration A methodology for integrating the views into a global database schema 1. Identifying correspondences and conflicts among the schemas Naming conflicts Type conflicts Domain (value set) conflicts Conflicts among constraints 2. Modifying views to conform to one another 3. Merging of views 4. Restructuring

25 FIGURE 12.4 Modifying views to conform before integration.

26 ACM TODS Transactions on Database systems 1976 Vol. 1, No. 1, 1(1) IEEE TKDE Transactions on Knowledge and Data Engineering VLDB Journal DKE Data and Knowledge Engineering IJCSSE Int l Journal of Computer

27 FIGURE 12.4 (continued) Modifying views to conform before integration.

28 FIGURE 12.5 Integrated schema after merging views 1 and 2 TITLE

29 Several strategies proposed for the view integration process Binary ladder integration N-ary integration Binary balanced strategy Mixed strategy

30 FIGURE 12.6 Different strategies for the view integration process.

31 Phase 3. Choice of a DBMS The following costs must be considered Software acquisition cost Maintenance cost Hardware acquisition cost Database creation and conversion cost Personnel cost Training cost Operating cost Economic and organizational factors Organization-wide adoption of a certain philosophy: the acceptability of a certain data model (relational vs object), a certain vendor, or a certain development methodology and tools Familiarity of personnel with the system Availability of vendor services

32 Phase 4. Data model mapping (also called logical database design) Map (or transform) the conceptual schema from the high-level data model used in Phase 2 into the data model of the chosen DBMS The result of this phase is a conceptual schema in the chosen data model The design of external schemas (views) for specific applications is often done during this phase

33 Phase 5. Physical database design Design the specifications for the stored database in terms of physical storage structures, record placement, and indexes This corresponds to designing the internal schema Criteria to guide the choice of physical database design options Response time Space utilization Transaction throughput

34 Phase 6. Database system implementation and tuning The database and application programs are implemented, tested, and eventually deployed for service Various transactions and applications are tested individually and then in conjunction with each other This reveals opportunities for physical design changes, data indexing, reorganization, and different placement of data an activity referred to as database tuning

35 Database Planning, Design, and Administration Chapter 9, Connolly & Begg

36 Databsae system development cycle

37 Database planning Planning how the stages of the lifecycle can be realized most efficiently and effectively System definition Specifying the scope and boundaries of the database system, including the major user views, its users, and application areas Requirement collection and analysis Collection and analysis of the requirements for the new database system Database design Conceptual, logical, and physical design of the database

38 DBMS selection (optional) Selecting a suitable DBMS for the database system Application design Designing the user interface and the application programs that use and process the database Retrieval/update/mixed transactions Form/report design Prototyping (optional) Building a working model of the database system, which allows the designers or users to visualize and evaluate how the final system will look and function Implementation Creating the physical database definitions and the application programs

39 Data conversion and loading Loading data from the old system to the new system and, where possible, converting any existing applications to run on the new database Testing Database system is tested for errors and validated against the requirements specified by the users Operational maintenance Database system is fully implemented. The system is continuously monitored and maintained. When necessary, new requirements are incorporated into the database system through the preceding stages of the lifecycle.

Practical Database Design Methodology and Use of UML Diagrams Design & Analysis of Database Systems

Practical Database Design Methodology and Use of UML Diagrams 406.426 Design & Analysis of Database Systems Jonghun Park jonghun@snu.ac.kr Dept. of Industrial Engineering Seoul National University chapter