Chapter 1

Front 1

Databases

Back 1

An organized collection of logically related data

Front 2

Structured data

Back 2

Numbers, text, dates

Front 3

Unstructured data

Back 3

Tweets, Facebook posts, pictures, GPS information, images, video, and documents

Front 4

Data

Back 4

A stored representation of objects and events that have meaning and importance in the users environment.

Front 5

Information

Back 5

Data processed to increase knowledge in the person using the data

Front 6

Metadata

Back 6

Data that describes the properties or characteristics of end user data in context. IE: Type, name, character length etc.

Front 7

Disadvantages of File Processing

Back 7

Program-Data Dependence, Lengthy Development Times, Data Duplication, Limited Data Sharing, Excessive Program Maintenance

Front 8

Problems with Data Dependency

Back 8

1. app programmer must maintain own data.

2. each app has to include code for the metadata of each file.

3. app dependent processing routines for reading, inserting, updating, and deleting data.

4. Lack of coordination of central control.

5. Non-standard file formats.

Front 9

Problems with Data Redundancy

Back 9

1. Wastes space to have duplicate data.

2. Causes more maintenance headaches.

3. Data changes in one file could cause inconsistencies. aka compromises data integrity.

Front 10

Database Approach

Back 10

1. Central repository of shared data.

2. Data is managed by a controlling agent.

3. Stored in a standardized, convenient form.

** Requires a DBMS, designed by creating Data Models, which explain Relational Databases and Entities.

Front 11

Data Model

Back 11

Capture the nature and relationship among data and are used at different level of abstraction as a database is conceptualized and developed.

Front 12

Database Management System (DBMS)

Back 12

Software that is used to manage the database approach. IE: SQL Server, MySQL, Oracle, etc.

manages data resources the way an OS manages hardware resources.

Front 13

Entities

Back 13

Describes a person, place, thing, object, process that is used to represent a need of the business process. IE. Customer, Order, Product, Inventory.

Front 14

Relational Database

Back 14

Establishes relationships between entities (tables) by means of common fields. Usually one to many 1:M or many to many M:N

Front 15

Advantages of the Database approach

Back 15

1. Program-Data Independence.

2. Planned data redundancy

3. Improved data consistency.

4. Improved data sharing.

5. Increased app dev productivity.

6. Enforcement of standards (constraints)

7. Improved data accessibility.

8. Improved data quality.

9. Reduced program maintenance.

10. Improved decision support.

Front 16

Program-Data Independence

Back 16

Metadata is stored in the database rather than in the application.

Front 17

User-View

Back 17

A logical description of some portion of the database that is required by users to perform a task. IE. Reporting schema, Inventory views, order views etc.

Front 18

Constraint

Back 18

A rule that cannot be violated in the database.

Front 19

Costs and Risks of the Database Approach

Back 19

1. New specialized personnel (me.)

2. Installation and management costs and complexity (think new MDS/Maestro, Inner-connectivity of systems, and version comparability).

3. Conversion Costs.

4. Need for explicit backup and recovery.

5. Organization conflict.

Front 20

Components of the Database Environment

Back 20

1. Case Tools.

2. Repository.

3. DBMS

4. Database.

5. Application Porgrams.

6. User Interface.

7. Data/Database Admins.

6. System Developers.

7. End Users.

Front 21

Case Tools

Back 21

Computer-aided software engineering.

Front 22

Repository.

Back 22

Centralized storehouse of metadata.

Front 23

Application Program

Back 23

Software using the data.

Front 24

User Interface

Back 24

Text and graphical displays to users.

Front 25

Database Admins

Back 25

Personnel responsible for maintaining the database.

Front 26

System Developers

Back 26

Personnel responsible for designing databases and software.

Front 27

End Users

Back 27

people who use the applications and databases.

Front 28

Enterprise Data Model

Back 28

First step in database dev model. Specifies scope and general content. Overall picture of organizational data at high level of abstraction. Entity-Relationship diagram. Descriptions of entity types. Relationships between entities. Business rules.

Front 29

System Development Life Cycle (SDLC)

Back 29

Detailed, well-planned development process. Time-consuming, but comprehensive. Long development cycle.

Planning > Analysis > Logical Design > Physical Design > Implementation > Maintenance

Front 30

Prototyping.

Back 30

Rapid Application Development (RAD), Cursory attempt at conceptual data modeling. Define database during development of initial prototype. Repeat implementation and maintenance activities with new prototype versions.

Front 31

Planning - SDLC - Enterprise Modeling

Back 31

- Analyze current data processing

- Analyze the general business functions and their database needs.

- Justify need for new data and databases in support of business.

Front 32

Planning - SDLC - Conceptual Modeling

Back 32

- Identify scope of the database requirements for proposed information system.

- Analyze overall data requirement for business function supported by database.

Front 33

Analysis - SDLC - Conceptual Modeling

Back 33

- Develop preliminary conceptual data model, including entities, relationships, attributes, and business rules.

- Compare preliminary conceptual data model with enterprise data model.

- Make conceptual data model consistent with other models of information system.

- Populate repository with all conceptual DB specifications.

Purpose: To analyze the business situation thoroughly to determine requirements, to structure those requirements, and to select among competing system features.`

Front 34

Design - SDLC - Logical DB Design

Back 34

- Analyze the transactions, forms, displays, and inquiries/views required by the business functions supported by the DB

- integrate db views into conceptual data model.

- identify data integrity and security requirements and populate repository.

Purpose: To elicit and structure all information requirements; to develop all technology and organizational specifications.

Front 35

Design - SDLC - Physical DB design and defintion

Back 35

- Define DB to DBMS

- Decide on psychical organization of data.

- Design DB processing programs.

Purpose: to elicit and structure all information requirements: to develop all technology and organizational specifications.

Front 36

Implementation - SDLC - Database Implementation.

Back 36

- Code and test DB processing programs.

- Complete DB documentation and training materials.

- Install DB and convert data from prior systems.

Purpose: Write programs, build databases, test and install new systems, train users, and finalize documentation.

Front 37

Maintenance - SDLC - Database Maintenance

Back 37

1. Analyze DB and DB applications to ensure it is aligned with evolving information requirements.

2. Enhance DB performance.

3. Debug, and recover when corrupted.

Front 38

Conceptual Schema

Back 38

- Output of the conceptual modeling phase.

- E-R Models

Front 39

Logical Schema

Back 39

Details the conceptual schema in terms of the DB and it's DBMS (tables, columns, rows, primary keys, foreign keys, constraints in a relational model)

Front 40

Physical Schema

Back 40

set of specifications that describe how the logical schema will be stored in the DBMS/DB. Indexes, organization of records and files.

Front 41

Prototyping (RAD)

Back 41

Rapid application development is a type of prototyping. The difference between prototyping and SDLC is there isn't much design time. You rapidly iterate thought the analysis, design, implementation process and work with a user until the system enhancements are acceptable.

Front 42

External Schema

Back 42

This is the view for DB users. Combo of Enterprise data model, and the user views.

Front 43

Internal Schema

Back 43

Logical and Physical structures related to Logical and Physical schemas.

Front 44

Agile Software Development

Back 44

- A more reformed/institutionalized version of RAD.

-Work closely with business community. Collaboration.

-Response to change is easier. Go back to step one and reiterate.

Front 45

Managing Projects/Project

Back 45

- a planned undertaking of related activities to reach and objective that has a beginning and an end.

- Initiated by SDLC during planning stage.

- Executed during analysis, design and implementation.

- Closed at the end of implementation.

Front 46

Evolution of Database systems

Back 46

- Need for program data independence > reduced maintenance.

- Desire to manage more complex data types and structures.

- Ease of data access for less technical personnel.

- Need for more powerful decision support platforms.

Flat files > Hierarchical > Network > Relational ** > Object-Oriented and Object-Relational and Data warehousing

Front 47

Personal Databases - Database Applications

Back 47

Support one user. Single device (phone, pc etc). Risk not being able to integrated data.

Front 48

Multitier Client/Server Databases

Back 48

Several clients connecting to and retrieving/entering/manipulating data in single DB through a browser/program.

Front 49

Enterprise Applications

Back 49

- Enterprise Resource Planning (ERP) Systems - Integrate all enterprise functions. Manufacturing, Finance, Sales, Marketing, etc.

- Data warehousing implementations - integrated decision support system derived from various operational databases.