Tài liệu Module 4: Deriving a Logical Data Design doc

Module 1: Course OverviewModule 4: Deriving a Logical Data Design Module 5: Normalizing the Logical Data Design Logical DataDesign Entities andAttributes Activity 4.1: Deriving Entities

Module 4: Deriving a Logical Data

Design

Module 1: Course Overview

Module 4: Deriving a Logical Data Design Module 5: Normalizing the

Logical Data Design

Logical DataDesign

Entities andAttributes

Activity 4.1: Deriving Entities and Attributes from Data Requirements

DataRelationships

Entity/RelationshipModeling

Activity 4.2: Creating a

Logical Data Model

Module 4: Deriving a Logical Data Design

! Overview

" Logical Data Design

" Entities and Attributes

" Data Relationships

" Entity/Relationship Modeling

" Review

In this module

At the end of this module, you will be able to:

" Analyze data requirements to determine data entities and attributes

" Analyze data entities and attributes to determine their relationships

" Determine the cardinality and existence characteristics of a relationship

" Create an entity/relationship diagram

In this module, you will learn

about logical data design

and entity/relationship

modeling

! Logical Data Design

" The Need for a Logical Data Design

" Deriving Logical Data Services

In this section

In this section, you will learn about logical data design During this stage of the design process, you will develop a data structure and formalize the solution’s conceptual design

Slide Objective

To introduce the concept of

logical data design

Lead-in

This section discusses the

logical data design of a

solution

The Need for a Logical Data Design

" A logical data design:

requirements

The logical data design is the middle stage of the natural progression from conceptual design to physical design The process of deriving a logical data design from the conceptual data design accomplishes the following:

" Translates conceptual data needs into real data requirements

You must turn the conceptual data needs identified during conceptual design into actual entities and relationships that will define how the data interacts

" Helps organize your thinking about the data

You must ensure that the data elements identified in the conceptual design stage accurately depict the desired data for the business solution

" Focuses on the semantic details of the data relationships

You are forced to delve deeper into the solution’s data requirements and look at how data interacts within both the existing system and the proposed solution

" Provides a mechanism for communication

The logical design helps to document the data design for all interested parties to read and understand

Slide Objective

To discuss the reasons why

a logical data design is

necessary

Deriving Logical Data Services

" Organize data requirements into entities

" Identify data services

" Identify logical groups of services

" Identify the relationship between groups and entities

" Refine the design

Some of the questions that must be addressed during logical data design concern the data services, which determine how the data will be managed and manipulated Development of a logical design provides a road map of these services

Organize data requirements into entities

After the data requirements for a set of use cases have been collected, you need

to organize these data requirements into similar groups of information The groupings of requirements are referred to as entities The entities allow you to track all of the required data on a given subject

Identify data services

It is important to identify any services that will act upon data

For example, consider the timesheet from the Ferguson and Bardell, Inc case study Many steps must be taken to complete the timesheet during its life span Many employees will edit the timesheet or read its information An automated process may extract timesheet information into another database for reporting purposes

After determining how a particular entity will be used, you determine whether a service should exist that will act as the interface to that entity

Identify logical groups of services

" While developing the data services, you might find it beneficial to group services that act upon common data or upon common processes These groups of services can help bring consistency to the solution, whether they concern a process that manipulates an employee object or a set of objects that deal with bank accounts

Slide Objective

To introduce the logical data

services

Lead-in

When developing a solution,

you must address questions

regarding the data services

For example, consider the consultant, consultant manager, and administrative assistant from the Ferguson and Bardell, Inc case study All

of them have a need to interact, to some degree, with time and billing information that is stored in the system One data service might handle the submittal of timesheets from the consultants A second data service might handle the processing of timesheet data into billable data for the

administrative assistants The fact that all users of the Ferguson and Bardell, Inc system need to work with timesheet data does not necessarily mean that one all-encompassing data service should handle everything that needs to be done to the timesheet as a single category of data

" After the logical data services are grouped by functionality, you can design data services that handle the logical functionality needed by the solution

Identify the relationship between groups and entities

" The data that the services act upon typically does not exist in a vacuum and most real-life situations require that some type of relationship exist between data Relationships between the services and data should be clearly defined Identifying the relationships provides greater logical design definition and enhances the functionality of the logical design

" At the logical level, it is important to know what relationships exist between data Later, these relationships will become part of the logical data model, which is a representation of the data; the users will work with the logical data model on a daily basis

" By identifying all the possible relationships, the development team can better understand the complete picture

Refine the design

" After organizing and analyzing entities, you will have to revisit the initial design and make refinements where necessary This reiteration through the design is a necessary process that will yield a more thorough and complete design

! Entities and Attributes

" Overview of Entities and Attributes

The data services are

represented in the logical

design by entities and

attributes

Overview of Entities and Attributes

" Entities and their corresponding attributes are the building blocks of relational design

" An entity is anything about which data will be collected and stored

" An attribute is a characteristic of an instance of an entity

When you move into the logical stage of data design, one of your first tasks is

to formulate entities from data requirements and other related information

An entity can be thought of as any person, place, thing, or concept that defines data or about which data will be collected and stored

An attribute is a characteristic that further defines and describes the properties

of an instance of an entity An entity can have multiple attributes

Think of entities as nouns and attributes as adjectives

Entities and attributes identified during logical design will be used later to help model the physical design

Entities and attributes form

the basis for logical design

When deriving entities, keep in mind that entities are:

" Objects about which information will be stored

The entities are the objects about which you wish to retain information Some examples of entities are Employees, Clients, and Timesheets

" The starting point for the logical data design

The identification of these entities is the first step in the design of a database

" The equivalent of rows in database tables

An instance of an entity will correspond to a row of a table

During requirements analysis, the following techniques will help you derive entities:

" Find use cases from gathered information

" Look, or listen, for nouns or noun phrases within the use cases Nouns describe people, places, things, or concepts

Consider the following example:

“Consultants enter their time into a timesheet on a weekly basis The timesheet

is then forwarded to the administrative assistant, who keys the time into the invoicing program The administrative assistant then sends invoices to the customers based on the time reported.”

The italicized words are possible candidates for entities After you have identified the entities, it is sometimes useful to write a short, one-sentence entity definition that will help determine relationships at a later time

Slide Objective

To introduce methods for

extracting entities from data

requirements

Lead-in

When deriving the entities of

a solution, keep the

following factors in mind

Delivery Tip

Point out that entities can

represent anything, from

people to books to hats

Deriving Attributes

" Descriptive information about an entity

" Attached to entity that they most closely describe

" Columns in database tables

" Example: Attributes of a car

" Should be attached to the entity that they most closely describe

An attribute can exist only when attached to an entity For example, the attribute of color does not describe anything tangible unless the color is applied to an object

" Define the columns in database tables

When the physical design is implemented, the attributes become the columns in the database tables

There is no specific method for identifying attributes Iteratively brainstorming about the characteristics of an entity can be sufficient If determining attributes

is difficult, you should check whether the definitions of the entities are sufficiently specific

Slide Objective

To introduce attributes

Lead-in

After identifying the entities,

you must determine which

of their attributes you want

to capture

Activity 4.1: Deriving Entities and Attributes from Data

Requirements

The process of identifying entities and attributes is the key to creating a logical data design This activity provides a real-world example of use case

requirements that you will analyze to identify entities and attributes

In each of the two exercises in this activity, you will analyze a single aspect of a logical data design At the end of each exercise, the class will discuss the design that you derived

After completing this activity, you will be able to:

" Identify and derive data entities from use cases

" Identify attributes of the derived data entities

Slide Objective

To practice identifying

entities and their attributes

Lead-in

In this activity, you will

identify entities and

attributes for the Ferguson

and Bardell, Inc case study

Delivery Tip

Make sure that students do

not tackle any physical

design during this activity It

is a very common error for

design teams to start

designing tables at this

stage That is not the intent

of this activity Keep the

students at the logical level

! Data Relationships

" Overview of Data Relationships

" Identifying Relationships Between Entities

" Overview of Cardinality and Existence

You will also learn how relationships can be further defined by looking at their cardinality and existence

In this section, you will look

at the relationships that bind

entities together

Overview of Data Relationships

" Represent associations between entities

" Bind entities together with a set of rules

" Allow you to represent real-life associations with data

After you have defined entities and their attributes, you need to identify any associations between the entities In the logical design process, these associations are known as relationships

Relationships act as binders between entities In essence, relationships define what entities have in common with each other The relationships that you define allow you to construct a real-life data model for a solution

Identifying Relationships Between Entities

" Relationships represent associations among entities

" Look for verbs or verb phrases that link entities together

Relationships link the entities For example, Employees belong to Departments; likewise, Departments have Employees

Relationships can be thought of as verbs or verb phrases that tie entities together These verbs are known as relation verbs

! To identify relationships

1 Look at the entity definitions

2 Identify verbs or verb phrases that characterize what actions entities perform

on each other These verbs are the relationships between the entities

Consider these examples (the relation verb is in bold):

" Consultants submit timesheets

" Administrative assistants invoice customers

" Customers request services of consultants

Slide Objective

To introduce entity

relationships

Lead-in

After entities have been

defined, the relationships

between them can be

identified

Overview of Cardinality and Existence

" Cardinality determines the number of instances of an entity that are allowed in a relationship

" Existence determines what entities must exist for the relationship to have meaning, given a specified cardinality

Cardinality and existence further define relationships between entities

Cardinality allows you to specify the number of instances of an entity that are allowed on each side of a relationship For example, one consultant can be on more than one project at a time

Existence allows you to specify whether one entity within a relationship can exist independently of another entity within the relationship, given a specified cardinality For example, there must be at least one consultant on a project The example shows a type of existence criteria that must be satisfied for the

relationship to have meaning

Slide Objective

To introduce the concepts of

cardinality and existence as

they apply to relationships

Lead-in

Cardinality and existence

determine the types of

relationships that entities

have with each other

Determining Cardinality

" Cardinality further defines a relationship by assigning it

to one of three major categories:

A single instance of an entity (known as the parent) is associated with zero

or more instances of another entity (known as the child)

The following is an example of a one-to-many relationship: Each library patron can have multiple books checked out at a time

" Many-to-many More than one instance of an entity is associated with more than one instance of another entity

The following is an example of a many-to-many relationship: A video store may rent a title to many different customers, and a specific customer might rent many titles at once; thus, many titles are rented to many customers

Cardinality can exist in one

of several different forms