Designing a database

→ 전체적인 디자인 과정을 이해해보자.

(교과서 읽으세염...)

• Initial phase
  • characterize fully the data needs of the prospective database users
• Second phase

  • choose a data model

    • Apply the concepts of the chosen data model
    • Translate the requirements into a conceptual schema of the database
    • A fully developed conceptual schema indicated the functional requirements of the enterprise
      • Describe the kinds of operations (or transactions) that will be performed on the data

    c.f NoSQL

    • Not Only SQL
• Final Phase
  • Move from an abstract data model to the implementation of the database
    • Logical Design
      • Deciding on the database schema
        • Database design requires that we find a "good" collection of relation schemas
        • Business decision
          • What attributes should we record in the database?
        • Computer Science decision
          • What relation schemas should we have and how should the attributes be distributes among the various relation schemas?
    • Physical Design
      • Deciding on the physical layout of the database

Design Phases

• In designing a database schema, we must ensure that we avoid two major pitfalls(위험)

  Redundancy

  • a bad design may result in repeated information

  Incompleteness

  • a bad design may make certain aspects of the enterprise difficult or impossible to model
  • 실행하는 데 불가능한 모델도 존재함

• Avoiding bad designs is not enough → good design!!!!

Design Approaches

Entity Relationship Model

• Models an enterprise as a collection of entities and relationships
  • Entity; a "thing" or "object" in the enterprise that is distinguishable from other objects
    • Described by a set of attributes
• Represented diagrammatically by an entity-relationship diagram (E-R diagram)

Normalization Theory

• Formalize what designs are bad, and test for them

E-R diagrams

• Mapping cardinalites
• Primary keys in E-R models
• Weak Entity sets
• Reduction to relation schemass