lecture 3

• Database Model

  • Three layers: conceptual (business ), logical (architects), and physical (DBAs/Developers)
  • Different purposes and completed times
  • necessary for successful data
• Stages of developing a database

  • Requirement: interviews, observations, data gathering
  • Design: data model created, integrity constraints, business rules created
  • Implementation: construct database, fill database, write documentation, train end users

  
• Conceptual Layer

  • written on board
  • Functional requirements
  • Easy to understand and modify
  • Unstructured
  • informal
  • no relationships
• Logical Layer

  • attributes/fields for each table
  • primary keys and foreign keys defined
  • identify objects of importance
  • user-friendly names
  • which data stored
  • relationships defined
  • No DBMS system defined
  • Software needed
• Physical Layer

  • designed, structured, formal
  • Removed spaces from table names
  • Data types defined (ex. Char, integer)
  • Specific to DBMS
  • Technical doc that is not easy for end users
• Data Relationships (Cardinality)

  • connects tables (entities) together via fields (attributes)
  • 3 different relationships: one to one, one to many, many to many
  • needed to verify no redundant fields
• One to One relationship

  • each attribute is associated with a single record in another table
• one to many relationships

  • each attribute in a table is associated with a multiple records in another table
• Many to many relationships

  • each attribute in a table is associated with multiple records in another table
• Relational Model

  • data organized into tables
  • each row called a record
  • each row has a unique key
  • each column called attribute
  • easy to expand the database with new tables
  • allows data integrity (No null values)
  • allows data normalization
• hierarchical Model

  • tree-like structure
  • data stored as records
  • records are connected through links
  • each child must only have one parent
  • each parent can have one or more children
  • not versatile. Only specific use cases
• object-oriented model

  • store objects and not data
  • real-world
  • multi-media apps
  • models complex objects
  • fast access via pointers
  • can be used on top of a relational database