to know the main stages of the database lecture 3 …...administration & fact finding techniques...

MIT-533 Database Systems 2 Lecture 3: DB Planning, Design and Administration/Fact Finding 1

Lecture 3 Database Planning, Design and

Administration & Fact Finding Techniques

Walailuk University

MIT 533 ระบบฐานขอมูล 2

Lecture 3: DB Planning, Design and Administration/Fact Finding 2MIT-533 Database Systems 2

Objectives (I)To know the main stages of the database application lifecycle.To understand the overall of DB system development: Planning, Design and AdministrationTo understand the main phases of database design: conceptual, logical, and physical design


Software Development LifecycleMajor reasons for failure of software projects

lack of complete requirements specificationlack of appropriate development methodologypoor decomposition of design into manageable components

Solution - a structured approach to development of software called Information System Development Lifecycle.


Information System (IS)Resources that enable the collection, management, control, and dissemination of information throughout an organization. Components of IS include

DatabaseDatabase softwareApplication softwareComputer hardware including storage mediaPersonnel using and developing the system

IS lifecycle include planning, requirements collection and analysis, design (including database design), prototyping, implementation, testing, conversion, and operational maintenance.


Database Application Lifecycle1. Database planning2. System definition3. Requirements

collection and analysis

4. Database design5. DBMS selection

(optional)6. Application design7. Prototyping

(optional)8. Implementation9. Data conversion

and loading10. Testing11. Operational

maintenance11


Step 1: Database PlanningDatabase Planning:

Management activities that allow the stages of the database application to be realized as efficiently and effectively, as possible.Mission statement and objectives: identifies work to be done; the resources with which to do it; and the money to pay for it all.Integrated with the overall IS strategy of the organization.


Database PlanningDatabase Planning

Include development of standards that govern:

how data will be collected,how the format should be specified, what necessary documentation will be needed,how design and implementation should proceed.


Step 2: System DefinitionSystem Definition

The scope and boundaries of the database application including its major application areas and user views.User view defines what is required of DB application:

A particular job role (such as Manager or Supervisor) or Enterprise application area (i.e., marketing, personnel,..).Database application may have one or more user views.

Identifying user views helps ensure that no major users of the DB are forgotten when developing requirements for an application. User views also help in development of complex DB application allowing requirements to be broken down into manageable pieces.


Representation of a Database Application with Multiple User Views


Step 3: Requirements Collection and AnalysisRequirements Collection and Analysis

The process of collecting and analyzing information about the part of the organization that is to be supported by the database application, and using this information to identify the users’ requirements of the new system.


Requirements Collection and AnalysisInformation is gathered for each major user view including:

a description of data used or generated;details of how data is to be used/generated;any additional requirements for new database application.

Information is analyzed to identify requirements to be included in new database application.Another important activity is deciding how to manage database application with multiple user views.


Step 4: Database DesignDatabase Design

The process of creating a design for a database that will support the enterprise’s operations and objectives. Major aims include:

Represent data and relationships between data required by all major application areas and user views.Provide data model that supports any transactions required on data.Specify a minimal design that achieves the stated performance requirements for the system such as response times.


Step 5-6: DBMS Selection and Application DesignDBMS Selection

The selection of an appropriate DBMS to support the DB application.Undertaken at any time prior to logical design provided sufficient information is available regarding system requirements.

Application DesignDesign of user interface/application programs that use the DB.Database and application design are parallel activities.


Database DesignTo assist in understanding of the meaning (semantics) of the data.To facilitate communication about requirements.


Conceptual Database DesignConceptual Database Design

The process of constructing a model of the information used in an enterprise, independent of all physical considerations.

Data model is built using the information in users’ requirements specification. Source of information for the logical design phase.


Logical DB Design and Physical DB DesignLogical Database Design

The process of constructing a model of the information used in an enterprise based on a specific data model (e.g. relational), but independent of a particular DBMS and other physical considerations.The conceptual data model is refined and mapped on to a logical data model.

Physical Database DesignThe process of producing a description of the implementation of the database on secondary storage.Describes the storage structures and access methods used to achieve efficient access to the data.Tailored to a specific DBMS system.


Two Approaches in DB DesignA logical model that represents multiple user views of an organization is called a global logical data model. There are two major approaches to merge user views.

CentralizedMerge separate user requirements that represent distinct user views into a single set of user requirements, and then build the global logical data model.

View integrationMerge separate local logical data models that represent distinct user views into one global logical data model.


Centralized Approach(DB Design)

Requirements for each user view are merged into a single set of requirements. A global data model is created based on the merged requirements (which represents all user views).


View Integration Approach (DB Design)

Requirements for each user view are used to build a separate data model.Data model representing single user view is called a local data model, composed of diagrams and documentation describing requirements of a particular user view of database. Local data models are then merged to produce a global data model, which represents all user views for the database.


An Example - Corporate Data Model(ER Diagram)


Physical Database DesignThe process of producing a description of the implementation of the database on secondary storage.Describes the storage structures and access methods used to achieve efficient access to the data.Tailored to a specific DBMS system.

ANSI-SPARCArchitecture and

Database Design Phases


DBMS SelectionDefine Terms of Reference of studyMake a short list of two or three productsEvaluate products Recommend selection and produce report


DBMS Evaluation Features


Example - Evaluation of DBMS Product


Application DesignIncludes two important activities

Transaction designUser interface design

Transaction DesignAn action or series of actions, carried out by a single user or application program, which accesses or changes the content of the database.Purpose to define and document the high-level characteristics of the transactions required on the database system.

User Interface DesignTo design the layout for forms or reports


Transaction Design(Application Design)

Important characteristics of transactions include

Data to be used by the transactionFunctional characteristics of the transactionOutput of the transactionImportance to the usersExpected rate of usage

Three main types of transactions: retrieval, update and mixed.


User Interface Design Guidelines(Application Design)

Meaningful titleComprehensible instructionsLogical grouping and sequencing of fieldsVisually appealing layout of the form/reportFamiliar field labelsConsistent terminology and abbreviationsConsistent use of colorVisible space and boundaries for data-entry fieldsConvenient cursor movementError correction for individual characters and entire fieldsError messages for unacceptable valuesOptional fields marked clearlyExplanatory messages for fieldsCompletion signal


Computer-Aided Software Engineering (CASE) Tools

Purpose - To support the efficient and effective development of database applications. Including

A data dictionary to store information about the database application’s data.Design tools to support data analysis.Tools to develop the conceptual, and logical data models.Tools to enable the prototyping of applications.


Categories of CASE ToolsDivided into three categories: upper-CASE, lower-CASE, and integrated-CASE, providing the following benefits:

StandardsIntegrationSupport for standard methodsConsistencyAutomation


DB Application Lifecycle - CASE Tools


Step 7: PrototypingPrototyping

To identify features of a system that work well, or are inadequateTo suggest improvements or even new featuresTo clarify the users’ requirements To evaluate the feasibility of a particular system design.


Step 8: ImplementationImplementation

Physical realization of the database and application designs.Use DDL of DBMS to create DB schemas and empty DB files and Use DDL to create any specified user views.Use 3GL or 4GL to create application programs. Parts of these programs are the DB transactions, created using DML of DBMS possibly embedded in a host programming language.


Step 9: Data Conversion and LoadingData Conversion and Loading

Transferring any existing data into the new DB and converting any existing applications to run on it.Required when a new DB system replaces an old one.


Step 10: TestingDB System Testing

The process of executing the application programs with the intent of finding errors.Use carefully planned test strategies and realistic data. Testing cannot show the absence of faults; it can show only that software faults are present.Demonstrates that database and application programs appear to be working according to requirements.


Step 11: Operational MaintenanceOperational Maintenance

The process of monitoring and maintaining the system following installation.Monitoring the performance of the system. If performance falls, may require tuning or reorganization of the database.Maintaining and upgrading the database application (when required). Incorporating new requirements into the database application.


Context Diagram (I)A System Context Diagram (SCD) is the highest level view of a system, showing the system as a whole and its inputs and outputs from/to external actors. SCDs are a type of Data Flow Diagram, and they should always be produced as DFDs. Context Diagrams show the interactions between a system and other actors with which the system is designed to face. SCD is very helpful in understanding the context in which the system will be part of Software engineering.Context diagrams are typically drawn using labeled boxes to represent each of the external entities and another labeled box to represent the system being developed. The relationship is drawn as a line between the entities and thesystem being developed. The relationships are labeled with a subject-verb-object format.


Context Diagram (II)Context diagrams can also use many different drawing types to represent external entities, such as ovals, stick figures, pictures, clip art or any other to convey meaning.Context diagrams are used early in a project to get agreement onthe scope under investigation. These diagrams must be read by all project stakeholders and thus should be written in plain language so the stakeholders canunderstand items within the document.An alternative would be a use case diagram since it also represents the project scope at a similar level of abstraction.The best System Context Diagrams are used to display how system interoperates at a very high level or how systems operateand interact logically. The system context diagram is a necessary tool in developing a baseline interaction between systems and actors; actors and system or systems and systems.


Context Diagram (III)


Data Flow Diagram (I)The dataflow diagram is one of the most commonly used systems-modeling tools, particularly for operational systems in which the functions of the system are of paramount importance and more complex than the data that the system manipulates.DFDs were first used in the software engineering field as a notation for studying systems design issues (e.g., in early structured design books and articles such as (Stevens, Myers, and Constantine. 1974), (Yourdon and Constantine, 1975), (Myers, 1975), et al.).In turn, the notation had been borrowed from earlier papers on graph theory, and it continues to be used as a convenient notation by software engineers concerned with direct implementation of models of user requirements.


Data Flow Diagram (II)This is interesting background, but is likely to be irrelevant to the users to whom you show DFD system models; indeed, probably the worst thing you can do is say, “Mr. User, I’d like to show you a top-down, partitioned, graph-theoretic model of your system.”Actually, many users will be familiar with the underlying concept of DFDs, because the same kind of notation has been used by operations research scientists for nearly 70 years to build work-flow models of organizations. This is important to keep in mind: DFDs cannot only be used to model information-processing systems, but also as a way of modeling whole organizations, that is, as a tool for business planning and strategic planning.


Data Flow Diagram (III)Keep in mind that the DFD is just one of the modeling tools available to the systems analyst and that it provides only one view of a system — the function-oriented view. If we are developing a system in which data relationships are more important than functions, we might de-emphasize the DFD (or conceivably not even bother developing one) and concentrate instead on developing a set of entity-relationship diagrams as discussed in Chapter 12. Alternatively, if the time-dependent behavior of the system dominated all other issues, we might concentrate instead on the state-transition diagram discussed in Chapter 13.


DFD Level 0Shows all the processes that comprise the overall systemShows how information moves from and to each processAdds data stores


DFD Level 0


DFD Elements


Context Diagram to DFD Level 0


DFD Level 1Shows all the processes that comprise a single process on the level 0 diagramShows how information moves from and to each of these processesShows in more detail the content of higher level processLevel 1 diagrams may not be needed for all level 0 processes


DFD Level 0 to DFD Level 1


DFD Level 2Shows all processes that comprise a single process on the level 1 diagramShows how information moves from and to each of these processesLevel 2 diagrams may not be needed for all level 1 processesCorrectly numbering each process helps the user understand where the process fits into the overall system


DFD Level 1 to DFD Level 2


Miracle

Black Hole

Gray HoleDFD Common Error


DFD Packet Concept

Pay phonebill

1

Telephone ServiceProvider

Itemized calls & invoice

Itemized calls

Invoice

Incorrect useof the packet

concept

Correct useof the packet

concept


Illegal Data Flows

to know the main stages of the database lecture 3 …...administration & fact finding techniques...

Documents