DBLC_to_recovery - The Database Life Cycle (DBLC) Within...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
The Database Life Cycle (DBLC) Within larger information systems, the database is subject to a life cycle. It goes hand in hand with the System/Software Development life Cycle (SDLC). 1. Database Initial Study a. Analyse the company situation b. Define problems and constraints c. Define objectives d. Define scope and boundaries 2. Database Design a. Create the conceptual design b. DBMS software selection c. Create the logical design d. Create the physical design 3. Implementation and Loading a. Install the DBMS b. Create the database(s) c. Load or convert the data 4. Testing and Evaluation a. Test the database b. Fine-tune the database c. Evaluate the database and its application programs 5. Operation a. Produce the required information flow 6. Maintenance and evolution a. Introduce changes b. Make enhancements Database Initial Study Database Design Detailed Design Implementation and Loading Coding Analysis Database Maintenance and Evolution Application program maintenance Testing and Evaluation Operation Testing and Evaluation
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Database Design Strategies Classic Approaches: 1. Top-down design starts by identifying the data sets, then defines the data elements for each of those sets. The entities are defined before the attributes per entity. 2. Bottom-up design first identifies the data elements (items), then groups them together in data sets. The attributes are defined first then are grouped to form the entities. . The design approach used often depends on the scope of the problem and on personal preferences. The approaches are complementary rather than mutually exclusive. Database Design Philosophies The choice of design philosophy is essentially based on the company’s structure as well as the scope and size of the system. 1. Centralized design is more productive when the data component is composed of a relatively small number of objects and procedures. The database design can be represented in a fairly simple database. A single conceptual design is completed and then validated. 2. Decentralized design is more appropriate for systems with data components that have a considerable number of entities and complex relations on which complex operations are performed. It is also applied when the problem itself is spread across several operational sites and each element is a subset of the entire data set. Transaction Management and Concurrency Controls Basically, a transaction is any action that reads from and/or writes to a database. It may be as simple as a SELECT statement; it may consist of any combination of SELECTs, INSERTs, UPDATEs and/or DELETEs. A transaction is a logical unit of work that must be entirely completed or entirely aborted. A successful transaction changes the database from one consistent state to another. A consistent database state is one in which all data integrity constraints are satisfied. Thus, to ensure consistency of the database, every transaction must begin with the database in a known
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 10

DBLC_to_recovery - The Database Life Cycle (DBLC) Within...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online