Chapter 2 Database Planning and Database Architecture 1
Preview:
Citation preview
- Slide 1
- Chapter 2 Database Planning and Database Architecture 1
- Slide 2
- Data as a Resource 2 Resource: an asset that has value and
incurs cost Resources include capital equipment, financial assets,
personnel and data Database is a resource because Operational data
has value Database incurs cost Professionally managed by DBA
- Slide 3
- Three Levels of Data 3 1. Real world Enterprise in its
environment Mini-world, or Universe of Discourse part of the world
that is represented in the database 2. Conceptual or Logical level
of data Entities, entity sets, attributes, relationships Metadata,
data about data Structure, record types, data item types, data
constraints, data aggregates Stored in data dictionary 3. Data
occurrences / Existence of data Database itself Data instances
files
- Slide 4
- Three Levels of Discussing Data 4 RealmObjectsExamples Real
World Containing Miniworld Enterprise Some aspects of the
enterprise Corporation, university, bank Human resources Student
enrollment Customers and accounts Conceptual Model or Logical Model
Metadata: data definitions, stored in Data Dictionary also known as
Catalog Entitty Attribute Entity set Relationship Record type Data
item type Data Aggregator A student, a class Name, schedule All
students, all classes Student entity relates to class entity by
being enrolled in it Student record type, Class record type stuid,
classNumber Address, consisting of street, name, state, ZIP Data
Occurrences stored in the database Student record occurrence Data
item occurrence File Database Record of student Tom Smith S1001,
Smith, Tom,History,90 Student file with 5000 Student records
University database containing Student file, Class file, Faculty
file,
- Slide 5
- Database Design 5 Systems analysis approach to design assumes
every system has a lifecycle, and will eventually be replaced
Staged database design centers on first developing a conceptual
model that evolves and survives
- Slide 6
- Characteristics of a Conceptual Database Model 6 Faithfully
mirrors the operations of the organization Flexible enough to allow
changes as new information needs arise Supports many different user
views Independent of physical implementation Does not depend on the
model used by a particular database management system
- Slide 7
- Stages in Database Design 7 Analyze user environment Develop
conceptual data model Choose a DBMS Develop logical model, by
mapping conceptual model to DBMS Develop physical model Evaluate
physical model Perform tuning, if indicated Implement physical
model See Figure 2.3 note loopsFigure 2.3 Analyze User Environment
Develop Conceptual Model Choose DBMS Develop Logical Model Develop
Physical Model Evaluate Physical Model Tune System Implement System
Figure 2.3 Steps in Staged Database Design
- Slide 8
- Design Tools 8 CASE (Computer-Aided Software Engineering) tools
Upper case: used for collecting and designing data, designing
logical model, designing applications Lower case: used for
implementing the database, including prototyping, data conversion,
generating application code, generating reports, testing Data
dictionary Data flow diagram
- Slide 9
- Data Dictionary 9 Contains metadata Can be integrated (part of
DBMS) or free-standing Useful for Collecting information about data
in central location Securing agreement on meanings of items
Communicating with users Identifying inconsistencies synonyms and
homonyms Keeping track of changes to DB structure Determining
impact of changes to DB structure Identifying sources
of/responsibility for items Recording external/logical/physical
models & mappings Recording access control information
Providing audit information
- Slide 10
- Three-level Database Architecture 10 CODASYL DBTG and ANSI
reports proposed viewing database architecture at 3 levels of
abstraction external, logical, internal - each with a written
description called a schema Rationale for separation of external
and internal levels Different users need different views of same
data Users data needs may change over time Hides complexity of
database storage structures Can change logical structure without
affecting all users Database structure unaffected by changes to the
physical aspects of storage See figure in book
- Slide 11
- 11
- Slide 12
- External Level 12 Consists of many user models or views Has
external records - records seen by users May include calculated or
virtual data Described in external schemas (sub-schemas) Used to
create user interface
- Slide 13
- Logical Level 13 Entire information structure of database
community view as seen by DBA Collection of logical records All
entities, attributes, relationships represented Includes all record
types, data item types, relationships, constraints, semantic
information, security and integrity information Relatively constant
over time Described in logical schema Used to create logical record
interface
- Slide 14
- Internal Level 14 The DBMS and Operating System View Physical
implementation level Includes data structures, file organizations
used by DBMS Depends on what DBMS is used Described in internal
schema Used to create stored record interface with operating system
Operating system creates physical files and physical record
interface
- Slide 15
- Data Independence 15 Logical data independence The capacity to
change the logical model without having to change the external view
or application programs. Immunity of external models to changes in
the logical model Occurs at user interface level Physical data
independence Immunity of logical model to changes in internal model
Occurs at logical interface level
- Slide 16
- Data Sublanguages 16 Every DBMS uses a data sublanguage to
describe and maintain the database, which has two parts Data
definition language (DDL) - used to define the database Used by the
DBA and database designers to specify the conceptual schema of a
database. In many DBMSs, the DDL is also used to define internal
and external schemas (views). Data manipulation language (DML) - is
used to process the database Data sublanguage may be embedded in a
general programming language (such as Java, C, C++, C#, COBOL, and
so on) which is called the host language
- Slide 17
- Planning and Design Stage 17 Preliminary planning Identifying
user requirements Developing and maintaining the data dictionary
Designing the conceptual model Choosing a DBMS Developing the
logical model Developing the physical model
- Slide 18
- Development Phase 18 Creating and loading the database
Developing user views Writing and maintaining documentation
Developing and enforcing data standards Developing and enforcing
application program standards Developing operating procedures Doing
user training
- Slide 19
- Database Management Phase 19 Monitoring performance Tuning and
reorganizing Keeping current on database improvements
- Slide 20
- Data Models 20 Collection of tools for describing structure of
database Often includes a type of diagram and specialized
vocabulary Description of the data, relationships in data,
constraints on data, some data meanings Most permanent part in
database architecture corresponds to conceptual level or logical
level Intension or scheme of the database
- Slide 21
- Data Models (Cont) 21 Data Models can be divided into three
major types Semantic Data Models A semantic model, captures only
meanings Example: Entity Relationship Model (E-R Model) Record
Based Models They allow the designer to develop and specify the
logical structure and provide some options for implementation of
the design Examples Hierarchical Model Network Model Relational
Model Object Based Models Object Oriented Model Object / Relational
Model (Also known as Extended Relational Model will be seen in some
later lectures)
- Slide 22
- Entity-Relationship Model 22 Conceptual level model Proposed by
Peter Chen in 1970s Entities are real-world objects about which we
collect data Attributes describe the entities Relationships are
associations among entities Entity set set of entities of the same
type Relationship set set of relationships of same type
Relationships sets may have descriptive attributes Represented by
E-R diagrams
- Slide 23
- Entity-Relationship Model (Cont) 23 SymbolNameMeaningExample
RectangleEntityStudent EllipseAttributeSTDNAME DiamondRelationship
ENROLL LineLinkSTDNAME Student
- Slide 24
- Entity-Relationship Model (Cont) 24 Student CourseNO SCHEDUAL
STDID STDNAME CTITLE MAJORCREDITS Course ENROLL PROF Grade
ROOM
- Slide 25
- Relational Model 25 Record-based model Logical-level model
Proposed by E.F. Codd Based on mathematical relations Uses
relations, represented as tables Columns of tables represent
attributes Tables represent relationships as well as entities
Successor to earlier record-based modelsnetwork and
hierarchical
- Slide 26
- Relational Model - Example 26 STDIDSTDNAMEMAJORCREDITS S1001Ali
AhmadComputer Science60 S1002Kamal KhanMath40 S1003Shoaib
MansoorComputer Science60 C_IDCNAMEPROFSCHEDROOM Mth01ACalculus
IMutiullahMW9R25 Csc01AIntro to AlgoTalhaTuF10N45 Csc01BProgramming
IImranTuThF9N40 C_IDSTDIDGrade Csc01AS1001B+ Csc01BS1001A
Mth01AS1002B Csc01AS1002B Student - TableEnrollment - Table Class -
Table
- Slide 27
- Hierarchical Model 27 Hierarchical Database model is one of the
oldest database models. This model is like a structure of a tree
with the records forming the nodes and fields forming the branches
of the tree. The hierarchical structure contains levels, or
segments. A segment is the equivalent of a file systems record
type. Within the hierarchy, a higher layer is perceived as the
parent of the segment directly beneath it, which is called the
child. The hierarchical model depicts a set of one-to- many (1:M)
relationships between a parent and its children segments.
- Slide 28
- Hierarchical Model - Example 28 STDIDSTDNAMEMAJORCREDITS
C_IDCNAMEPROFSCHEDROOM Student Class
- Slide 29
- Hierarchical Model - Example 29 S1001Ali AhmadComputer Science
60 Csc01AIntro to AlgoTalhaTuF10N45 S1002Kamal KhanComputer Science
60 S1008Noman ChComputer Science 60
- Slide 30
- Network Model 30 The Network model replaces the hierarchical
tree with a graph thus allowing more general connections among the
nodes. The main difference of the network model from the
hierarchical model, is its ability to handle many to many (N:N)
relations. In other words, it allows a record to have more than one
parent. Suppose an employee works for two departments, or a student
taking two classes. The strict hierarchical arrangement is not
possible here and the tree becomes a more generalized graph a
network. The network model was evolved to specifically handle
non-hierarchical relationships. A network structure thus allows 1:1
(one:one), 1:M (one:many), M:M (many:many) relationships among
entities. In network database terminology, a relationship is a set.
Each set is made up of at least two types of records: an owner
record (equivalent to parent in the hierarchical model) and a
member record (similar to the child record in the hierarchical
model).
- Slide 31
- Network Model - Example 31 S1001Ali AhmadComputer Science 60
Csc01AIntro to Algo TalhaTuF10N45 S1002Kamal KhanComputer Science
60 S1008Noman ChComputer Science 60 Mth01ACalculus
IMutiullahMW9R25
- Slide 32
- Object-oriented Model 32 Similar to E-R but includes
encapsulation, inheritance Objects have both state and behavior
State is defined by attributes Behavior is defined by methods
(functions or procedures) Designer defines classes with attributes,
methods, and relationships Class constructor method creates object
instances Each object has a unique object ID Classes related by
class hierarchies Both conceptual-level and logical-level
model
- Slide 33
- Database Administrator Skills 33 DBA must be Technically
competent Good manager Have excellent interpersonal and
communication skills Has primary responsibility for planning,
designing, developing and managing the operating database Database
designer may do conceptual and logical design; DBA does physical
design, implementation and manages system