Unit 1 Database Design Concept · PDF fileDBMS – Unit 1 Database Design Concept 3 n Composite Entities l Used to ‘bridge’ between M:N relationships. l Bridge Entities, known

DBMS – Unit 1 Database Design Concept i

Unit 1 Database Design Concept

Table of Contents Entity Relationship Diagram ...................................................................................................... 1

Entities and Attributes ........................................................................................................ 1 Relationships ...................................................................................................................... 1 Artist Database ERD and Tables ........................................................................................ 3 General Rules Governing Relationships Among Tables .................................................... 3

Normalization Rules ................................................................................................................... 6 The Need for Normalization .............................................................................................. 6 Conversion to 1NF ............................................................................................................. 7 Conversion to 2NF ............................................................................................................. 8 Conversion to 3NF ............................................................................................................. 9 Boyce-Codd Normal Form (BCNF) ................................................................................. 10

Database Design ....................................................................................................................... 11 Changing Data into Information ...................................................................................... 11 The Information System ................................................................................................... 11 Systems Development Life Cycle .................................................................................... 12 Database Lifecycle (DBLC) ............................................................................................. 13

Phase 1: Database Initial Study ................................................................................ 14 Phase 2: Database Design ........................................................................................ 14 Phase 3: Implementation and Loading ..................................................................... 16 Phase 4: Testing and Evaluation ............................................................................... 17 Phase 5: Operation ................................................................................................... 17 Phase 6: Maintenance and Evaluation ...................................................................... 17

DB Design Strategy Notes ....................................................................................................... 18 Centralized vs. Decentralized Design ...................................................................................... 18 Database Management System ................................................................................................. 18

Installation and Uninstallation of Oracle Database Server ............. Error! Bookmark not defined.

DBMS – Unit 1 Database Design Concept 1

Entity Relationship Diagram – Represents the conceptual database as viewed by the end user. Entities and Attributes n Entity – l Corresponds to entire table, not to a row in the relational environment. l Represented by rectangle containing the entity name, which is a noun written in

capital letters. n Attributes – l Characteristics of entities – the STUDENT entity could include the attributes

STU_LNAME, STU_FNAME and STU_INITIAL. l Domain – domain is set of possible values u For the numeric attribute GPA is written (0,4) because the lowest and highest

possible GPA is 0 and 4, respectively. u For the character attribute SEX consists of only two possibilities, M or F. u For the date attribute HIRE_DATE consists of all dates from startup date to

current date. l Primary Keys – primary keys are underlined in the E-R diagram. u Format: TABLE NAME (KEY ATTRIBUTE 1, ATTRIBUTE 2, …) u For example, the CLASS_CODE is a primary key, then

CLASS (CLASS_CODE, CRS_CODE, CLASS_SECTION, CLASS_TIME, CLASS_ROOM, PROF_NUM) If the CLASS_CODE is deleted, then may be represented by CLASS (CRS_CODE, CLASS_SECTION, CLASS_TIME, CLASS_ROOM, PROF_NUM)

l Simple Attribute – Cannot be subdivided; ex: age, sex, marital status would be classified as simple attributes.

l Composite Attribute – Can be subdivided into additional attributes; ex: address into street, city, zip; Phone number into area code and exchange number.

l Single-valued Attribute – Can have only a single value; ex: person has one social security number.

l Multi-valued Attribute – Can have many values; ex: person may have several college degrees or householder may own more phone numbers.

l Derived Attribute – Can be derived with algorithm, instead of being physically stored within the database; ex: age can be derived from date of birth – by the integer value of difference between the current date and the employee’s date of birth.

Relationships – A relationship is an association between entities. For example, a STUDENT takes a


CLASS, a PROFESSOR teaches a CLASS, a DEPARTMENT employs a PROFESSOR, a DIVISION is managed by an EMPLOYEE, and AIRCRAFT is flown by a CREW, etc. The entities that participate in a relationship, i.e., connected entities, are called participants. n Connectivity and Cardinality l Connectivity describes relationship classification. It may be classified as 1:1, 1:M,

M:N. l Cardinality expresses the specific number of entity occurrences associated with one

occurrence of related entity. l Connectivity and cardinality are established by very concise statements known as

business rules, which is derived from a precise and detailed description of an organization’s data environment, also establish the E-R model’s entities, attributes, relationships, connectivities and constraints.

n Relationship Strength l Existence Dependence – Entity’s existence depends on existence of related entities l Weak (non-identifying) Relationships u PK of related entity doesn’t contain PK component of parent entity u For example, the definition of the COURSE and CLASS entities is

COURSE(CRS_CODE, DEPT_CODE, CRS_DESCRIPTION, CRS_CREDIT) CLASS(CLASS_CODE, CRS_CODE, CLASS_SECTION, CLASS_TIME,...)

l Strong (identifying) Relationships u PK of related entity contains PK component of parent entity u For example, the definition of the COURSE and CLASS entities is

COURSE(CRS_CODE, DEPT_CODE, CRS_DESCRIPTION, CRS_CREDIT) CLASS(CRS_CODE, CLASS_SECTION, CLASS_TIME,…)

l Weak Entities – In database design terms, the existence of a strong relationship between a parent entity and its related entity or entities is associated with weak entities.

n Relationship Participation l Optional u Entity occurrence does not require a corresponding occurrence in related entity u A PROFESSOR does not to teach a CLASS; i.e., CLASS is optional to

PROFESSOR u It indicates that the minimum cardinality is 0 for the optional entity.

l Mandatory u Entity occurrence requires corresponding occurrence in related entity. u The CLASS must be taught by a PROFESSOR; i.e., PROFESSOR is

mandatory to CLASS. u Indicates the minimum cardinality is 1 for the mandatory entity.


n Composite Entities l Used to ‘bridge’ between M:N relationships. l Bridge Entities, known as Composite Entities, composed of primary keys of each

entity needing connection. Artist Database ERD and Tables General Rules Governing Relationships Among Tables n M:N, Both Sides Mandatory


n M:N, Both Sides Optional n M:N, One Side Optional n 1:M, Both Sides Mandatory n 1:M, Both Sides Optional


n 1:M, Many Side Optional, One Side Mandatory n 1:M, One Side Optional, One Side Mandatory n 1:1, Both Sides Mandatory n 1:1, Both Sides Optional


n 1:1, One Side Optional, One Side Mandatory n Weak Entity, Foreign Key Located in Weak Entity n Multi-valued Attributes (1:M Relationship, Foreign Key CAR_VIN in the New Table) Normalization Rules The Need for Normalization n The simplified case illustration – for a construction company. l Manages several building projects. l Each project contains project number, name, employee, and so on. l Each employee has ID, name, job title, and so on. l The clients are charged by billing hours spent on each contract. The rate depends

on employee’s position, i.e., salary. l The total charge is shown on the figure below.


Conversion to 1NF n Repeating groups must be eliminated l Repeating groups, for example, any project number (PROJ_NUM) in the Figure,

can have a group of several data entries. l Make sure that each row defines a single entity. l Proper primary key developed; for example, uniquely identifies attribute values

(rows), combination of PROJ_NUM and EMP_NUM.

n Dependencies can be identified with help of the figure above, which is the dependency diagram shown in first normal form (1NF). l Desirable dependencies based on primary keys, which are bold, underlined, and

shared in a different color in the figure. l Less desirable dependencies, which is indicated with arrows below the dependency


diagram. Two types of dependencies exist: u Partial dependencies – based on part of composite primary key. u Transitive dependencies – one nonprime attribute depends on another

nonprime attribute. l The table structure can shown in the format:

TABLE_NAME(PRIMARY_KEY_ATTRIBUTE(S), DEPENDENT ATTRIBUTES) u Prime attribute (or key attribute), any attribute that is at least part of a key, e.g.,

PROJ_NUM and EMP_NUM. u Nonprime attribute (or nonkey attribute), is not even part of a key.

l 1NF Summarized u All key attributes defined u No repeating groups in table u All attributes dependent on primary key

Conversion to 2NF n Start with 1NF format: l Write each key component on separate line l Write original (composite) key on last line

PROJ_NUM EMP_NUM PROJ_NUM EMP_NUM

n Each component will become the key new table n Write dependent attributes after each key. For example herein, the three new tables,

PROJECT, EMPLOYEE, and ASSIGN, are described by PROJECT (PROJ_NUM, PROJ_NAME) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR) ASSIGN (PROJ_NUM, EMP_NUM, ASSIGN_HOURS)

n The conversion results of this operation are displayed in next page. (It still shows a transitive dependency, which can generate anomalies – the charge per hour changes for a job classification that is held by many employees.)

n 2NF Conversion Results l In 1NF l Includes no partial dependencies l No attribute dependent on a portion of primary key l Still possible to exhibit transitive dependency l Attributes may be functionally dependent on nonkey attributes


Conversion to 3NF n Break off the piece(s) that are identified by the transitive dependency arrow(s) below the

dependency diagram and storing them in separate table(s) to eliminate transitive functional dependencies PROJECT (PROJ_NUM, PROJ_NAME) ASSIGN (PROJ_NUM, EMP_NUM, ASSIGN_HOURS) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS) JOB (JOB_CLASS, CHG_HOUR)


n 3NF Summarized l In 2NF l Contains no transitive dependencies l Improve the database’s ability to provide information and to enhance it operational

characteristics for a completed database shown in previous page. l This conversion has eliminated the original EMPLOYEE table’s transitive

dependency; the tables are now said to be in third normal form (3NF). Boyce-Codd Normal Form (BCNF) n Every determinant in the table is a candidate key l Determinant is attribute whose value determines other values in row. l 3NF table with one candidate key is already in BCNF

n 3NF Table Not in BCNF, they both can be equivalent ONLY IF the table contains only one candidate key. l Most designers consider the BCNF as a special case of the 3NF. To determine a

table in 3NF but not in BCNF, note that u A transitive dependency exists when one nonprime attribute is dependent on

another nonprime attribute. u A table is in 3NF if it is in 2NF and there are no transitive dependencies.


Database Design Changing Data into Information n Data l Raw facts stored in databases l Need additional processing to become useful

n Information l Required by decision maker l Data processed and presented in a meaningful form l Transformation

The Information System n Database l Carefully designed and constructed repository of facts l Part of an information system

n Information System l Provides data collection, storage, and retrieval l Facilitates data transformation l Components include: u People u Hardware u Software ü Database(s) ü Application programs ü Procedures

l System Analysis u Establishes need and extent of an information system

l Systems development u Process of creating information system

l Database development u Process of database design and implementation u Creation of database models u Implementation ü Creating storage structure ü Loading data into database ü Providing for data management


Systems Development Life Cycle (SDLC)

Figure 2 n Planning l Should the existing system be continued, modified or replaced? l The technical of hardware and software requirements. l The system cost.

n Analysis l What are the precise requirements of the current system’s end users? l Do these requirements fit into the overall information requirements?

n Detailed system design – the designer completes the design of the system’s processes including all the necessary technical specifications for the screens, menus, reports, and other devices that might e used in help make the system a more efficient information generator.

n Implementation l Install the hardware, the DBMS software, and application programs.


l The system enters into a cycle of coding, testing, and debugging, until it is readto delivered.

l The actual database is created, and the system is customized, by using a variety of methods and devices: u Customized user programs u Database interface programs u Conversion programs that import the data from a different file structure, using

batch programs, a database utility, or both. n Maintenance l Corrective maintenance in response to system errors. l Adaptive maintenance due to changes in the business environment. l Perfect maintenance to enhance the system.

Database Lifecycle (DBLC)

Figure 3


Phase 1: Database Initial Study n Purposes l Analyze company situation u Operating environment u Organizational structure

l Define problems and constraints u Define objectives What is the proposed system’s initial objective? u Will the system interface with other existing or future systems in the company? u Will the system share the data with other systems or users?

l Define scope and boundaries n Initial Study Activities – Figure 4 Phase 2: Database Design n Most Critical DBLC phase n Makes sure final product meets requirements n Focus on data requirements n Sub-phases: l Create conceptual design l DBMS software selection l Create logical design l Create physical design

n Tow Views of Data: Business Manager and Designer – Figure 5 n I. Conceptual Design l Data modeling creates abstract data structure to represent real-world items l High level of abstraction l Four steps u Data analysis and requirements u Entity relationship modeling and normalization u Data model verification u Distributed database design

l Data analysis and Requirements u Focus on: ü Information needs ü Information users ü Information sources ü Information constitution

u Data sources ü Developing and gathering end-user data views ü Direct observation of current system


ü Interfacing with systems design group ü Business rules

l Entity Relationship Modeling and Normalization u Steps to develop the conceptual model using ERD

STEP ACTIVITY 1 Identify, analyze, and refine the business rules. 2 Identify the main entities, using the results of Step 1. 3 Define the relationships among the entities, using the results of Steps 1 and 2. 4 Define the attributes, primary keys, and foreign keys for each of the entities. 5 Normalize the entities. 6 Complete the initial ERD. 7 Have the main end users verify the model in Step 6 against the data, information and

processing requirements. 8 Modify the ERD, using the results of Step 7.

u E-R Modeling is Iterative – Figure 8 u Concept Design: Tools and Resource – Figure 9

l Data Model Verification u E-R model is verified against proposed system processes ü End user views and required transactions ü Access paths, security, concurrency control ü Business-imposed data requirements and constraints

u E-R Model Verification Process STEP ACTIVITY

1 Identify the E-R model’s central entity. 2 Identify each module and its components. 3 Identify each module’s transaction requirements;

Internal: Updates/Inserts/Deletes/Queries/Reports External: Module interfaces

4 Verify all processes against the E-R model. 5 Make all necessary changes suggested in Step 4. 6 Repeat Steps through 5 for all modules.

u Reveals additional entity and attribute details u Define major components as modules ü Cohesivity ü Coupling

u Iterative Process of Verification – Figure 10 l Distributed Database Design u Design portions in different physical locations


u Development of data distribution and allocation strategies n II. DBMS Software Selection l DBMS software selection is critical l Advantages and disadvantages need study l Factors affecting purchasing decision l Cost u DBMS features and tools u Underlying model u Portability u DBMS hardware requirements

n III. Logical Design l Translates conceptual design into internal model l Maps objects in model to specific DBMS constructs l Design components u Tables u Indexes u Views u Transactions u Access authorities u Others

n IV. Physical Design l Selection of data storage and access characteristics u Very technical u More important in older hierarchical and network models

l Becomes more complex for distributed systems u Designers favor software that hides physical details

l Physical Organization – Figure 12 Phase 3: Implementation and Loading n Creation of special storage-related constructs to house end-user tables n Data loaded into tables n Refer Figure 13 to compare parallel activities during implementation period in the DBLC

and the SDLC. n Other issues l Performance l Security u Physical security – allows physical access to areas by authorized personnel

only. u Password security – allows the assignment of access rights to specific


authorized users. u Access rights – restricts operations on predetermined objects such as databases,

tables, views, queries, and reports. u Audit trails – provide an after-the-fact device to check for access violations. u Data encryption – prevents unauthorized users who might have violated some

of the database security layers. u Diskless workstations – allow end users to access the database without being

able to download the information from their workstation. l Backup and recovery l Integrity l Company standards l Concurrency controls

Phase 4: Testing and Evaluation n Database is tested and fine-tuned for performance, integrity, concurrent access, and

security constraints n Done in parallel with application programming n Actions taken if tests fail l Fine-tuning based on reference manuals l Modification of physical design l Modification of logical design l Upgrade or change DBMS software or hardware

Phase 5: Operation n Database considered operational n Starts process of system evaluation n Unforeseen problems may surface n Demand for change is constant Phase 6: Maintenance and Evaluation n Preventative maintenance n Corrective maintenance n Adaptive maintenance n Assignment of access permissions n Generation of database access statistics to monitor performance n Periodic security audits based on system-generated statistics n Periodic system usage-summaries


DB Design Strategy Notes n Top-down Design l 1) Identify data sets l 2) Define data elements

n Bottom-up Design l 1) Identify data elements l 2) Group them into data sets

n Top-Down vs. Bottom-Up – Figure 6-14 Centralized vs. Decentralized Design n Centralized design – Figure 15 l Typical of simple databases l Conducted by single person or small team

n Decentralized design – Figure 16 l Larger numbers of entities and complex relations l Spread across multiple sites l Developed by teams

Database Management System n Oracle Database Server n MS SQL Server n DB2 n MySQL

Documents

Unit 1 Database Design Concept · PDF fileDBMS – Unit 1 Database Design Concept 3 n Composite Entities l Used to ‘bridge’ between M:N relationships. l Bridge Entities, known