Académique Documents
Professionnel Documents
Culture Documents
1. An information system is an arrangement of people, data, process, information presentation,
and information technology that interact to support and improve the operations in a business and
to support the problemsolving and decisionmaking needs of management and users.
2. Information technology is a contemporary term that describes the combination of computer
technology (hardware and software) with telecommunications technology (data, image, and
voice networks).
3. Information workers are the stakeholders in information systems. Information workers include
those people whose jobs involve the creation, collection, processing, distribution, and use of
information. They include:
a. System owners the sponsors and chief advocates of information system.
b. System users the people who use or are affected by the information system on a
regular basis. Geographically, system users may be internal, mobile, remote, or external.
c. System designers technology specialists who translate system users' business
requirements and constraints into technical solutions.
d. System builders technology specialists who construct the information system
components based on the design specifications.
e. Systems analysts the people who facilitate the development of information systems
and computer applications. They coordinate the efforts of the owners, users, designers, and
builders. Frequently, they may play one of those roles as well. Systems analysts perform
system analysis and design.
i) Systems analysis is the study of a business problem domain to recommend
improvements and specify the business requirements for the solution.
ii) Systems design is the specification or construction of a technical, computerbased
solution for the business requirements identified in a systems analysis.
f. Information technology vendors and consultants the people who bring external
expertise, experience, and human resource capacity to many projects.
4. The systems analyst facilitates most of the activities to develop or acquire an information
system. A systems analyst studies the problems and needs of an organization to determine how
people, data, process, communication, and information technology can best accomplish
improvements for the business.
5. A business analyst is a systems analyst that specializes in business problem analysis and
technologyindependent requirements analysis.
6. Most systems analysts work for the systems development group in the information services
group or department of a business. Alternatively systems analysts (under different titles) work
for IT consulting firms, outsources, and application software vendors.
7. Players in the information systems game are being affected by a number of business and
technology trends including:
a. Total quality management, a comprehensive approach to facilitating quality
improvements and management within a business.
b. Business process redesign, the study, analysis, and redesign of fundamental business
processes to reduce costs and/or improve value added to the business.
c. Continuous process improvement, the continuous monitoring of business processes to
effect small but measurable improvements to cost reduction and value added.
d. The year 2000 compatibility problem and the Euro currency conversion directive.
e. Enterprise resources planning, the selection and implementation of a single vendor's
fully integrated information system that spans most basic business functions required by a
major corporation.
f. Electronic commerce, a new way of doing business that involves conducting both
internal and external business over the Internet, intranets, and extranets.
8. The system analyst is a principal player in the information systems game. To prepare for a career
as a systems analyst you will need to gain:
a. A current working knowledge of information technology, which you must keep current.
b. Some computer programming experience and expertise.
c. General business knowledge and, if possible, business experience.
d. Better than average problemsolving skills.
e. Better than average interpersonal communication skills.
f. Strong interpersonal relations and teamwork skills.
g. Flexibility and adaptability to change as the problem and politics of business change.
h. Good character and strong ethics, necessary because analysts gain access to sensitive and
confidential data, facts, and opinions.
i. Systems analysis and design skillsthe subject of this book!
9. Prospects for a career as a systems analyst look bright through 2006 and beyond. A shortage of
analysts will fuel the prospects for those experienced analysts who have remained current with
the fastchanging world of information technology.
Chapter 2
1. Data are raw facts about a business and its business transactions. Information is data that has
been refined and organized by processing and purposeful intelligence.
2. An information system (IS) is an arrangement of people, data, processes, interfaces, and
communications that interact to support and improve daytoday operations in a business as well
as support the problemsolving and decisionmaking needs of management and users.
a. Information systems are enabled by information technology, a contemporaryterm that
describes the combination of computer technology (hardware and software) with
telecommunications technology (data, image, and voice networks).
b. Frontoffice information systems support business functions that reach out to customers
(or constituents).
c. Backoffice information systems support internal business operations as well as interact
with suppliers (of materials, equipment, supplies and services).
3. Information systems fulfill one or more of the following basic purposes:
a. Transaction processing systems capture and process data about (or of) business
transactions.
b. Management information systems provide essential management reports required to
plan, monitor, and control business operations.
c. Decision support systems provide users, especially managers, with decisionoriented
information in response to various unstructured decision and problemsolving opportunities.
(1) Decision support systems are built around data warehouses – readonly,
informational databases that are populated with detailed, summary, and exception data
and information that can be accessed by endusers and managers with DSS tools that
generate a virtually limitless variety of information in support of unstructured decisions.
d. Expert systems capture and simulate the knowledge and expertise of subject matter
experts so nonexperts may apply it.
e. Office automation (OA) systems support the wide range of business office activities that
provide for improved work flow and communications between workers, regardless of
whether or nor those workers are located in the same office.
(1) Personal information systems are those designed to meet the needs of a single user.
They are designed to boost an individual's productivity.
(2) Work group information systems are those designed to meet the needs of a work
group. They are designed to boost the group's productivity.
4. Information systems architecture provides a unifying framework into which various people with
different perspectives can organize and view the fundamental building blocks of information
systems. The framework used throughout this book is based on, and adapted from, the Zachman
“Framework for Information Systems Architecture.”
a. The information system framework is visually presented as a matrix. The rows
correspond to the perspectives of different stakeholders in the information system
development process. The columns correspond to a specific focus or dimension of the
information system that must be analyzed, designed, and implemented. Each cell represents
one perspective and one focus.
b. Although the cells can be studied and developed in isolation, they must be synchronized
with the other cells (both across rows and down columns) to develop a successful
information system.
5. The six perspectives are provided by:
a. System owners, who pay for the system to be built and maintained. They own the system,
set priorities for the system, and determine policies for its use.
b. System users, who actually use the system to perform or support the work to be
completed. System users define the business requirements and performance expectations for
the system to be built.
c. System designers, the technical specialists who design the system to meet the user's
requirements. In many cases, system designers may also be system builders.
d. System builders, the technical specialists who construct, test, and deliver the system into
operation.
e. Systems analysts, who facilitate the development of information systems and computer
applications by bridging the communications gap that exists between nontechnical system
owners and users technical system designers and builders.
f. IT vendors and consultants, who sell hardware, software and services to businesses for
incorporation into their information systems.
6. The three focuses represented in the model are:
a. DATA the raw material used to create useful information.
b. PROCESSES the activities (including management) that carry out the mission of
the business.
c. INTERFACES how the system interfaces with its users and other information
systems.
7. A fourth focus, COMMUNICATIONS, Was identified in the original Zachman framework but
is omitted from our framework because computer networks are not typically built in conjunction
with any single information system development project. Instead, computer networks are built in
separate projects to support the communication requirements for many information systems.
Regardless, the Communications focus can be viewed from the same perspective as the other
framework focuses.
Chapter 3
1. A system development process is a set of activities, methods, best practices, deliverables, and
automated tools that stakeholders use to develop and maintain information systems and
software.
2. The Capability Maturity Model (CMM) is a framework to assess the maturity level of an
organization's information system development and management processes and products. It
consists of five levels of measured by a set of guidelines called the key process areas.
a. Level 1 – Initial: This is sometimes called anarchy or chaos.
b. Level 2 – Repeatable:Project management processes and practices are established to
track project costs, schedules, and functionality.
c. Level 3 – Defined: A standard systems development process (sometimes called a
methodology) is purchased or developed and integrated throughout the information
systems/services unit of the organization.
d. Level 4 – Managed: Measurable goals for quality and productivity are established.
e. Level 5 – Optimizing: The standardized systems development process is continuously
monitored and improved based on measures and data analysis established in level 4.
3. A system life cycle divides the life of an information system into two stages, systems
development and systems operation and support – first you build it; then you use it.
A systems development methodology is a very formal and precise system development process
that defines a set of activities, methods, vest practices, deliverables, and automated tools that
system developers and project managers use to develop and maintain information systems and
softwares.
4. The following principles should underlie all systems development methodologies:
a. Get the owners and users involved. f. Don't be afraid to cancel or revise
b. Use a problemsolving approach. scope.
c. Establish phases and activities. g. Divide and conquer.
d. Establish standards. h. Design systems for growth and
e. Justify systems as capital investments. change
.
5. System development projects are triggered by problems, opportunities, and directives.
a. A problem is an undesirable situation that prevents the organization from fully achieving
its purpose, goals, and/or objectives.
b. An opportunity is a chance to improve the organization even in the absence of specific
problems.
c. A directive is a new requirement that's imposed by management, government, or some
external influence.
6. Wetherbe's PIECES framework is useful for categorizing problems, opportunities, and
directives. The letters of the PIECES acronym correspond to Performance, Information,
Economics, Control, Efficiency, and Service.
7. Traditional, basic systems development phases include:
a. Preliminary investigation. e. Design.
b. Problem analysis. f. Construction.
c. Requirements Analysis. g. Implementation.
d. Decision analysis.
8. Cross life cycle activities are activities that overlap many or all phases of the methodology. They
may include:
a. Factfinding
The formal process of using research, interviews, meetings, questionnaires, sampling,
and other techniques to collect information about systems, requirements, and preferences.
b. Documentation
The activity of recording facts and specification for a system for current and future
reference. Documentation is frequently stored in a repository, a database where system
developers store all documentation, knowledge, and products for one or more information
systems or projects.
c. Presentation
The activity of communicating findings, recommendations, and documentation for
review by interested users and managers. Presentations may be either written or verbal.
d. Feasibility analysis
The activity by which feasibility, a measure of how beneficial the development of an
information system would be to an organization, is measured and assessed.
e. Process management
The ongoing activity that documents, manages the use of, and improves an organization's
chosen methodology (the “process”) for systems development.
f. Project management
The activity of defining, planning, directing, monitoring, and controlling a project to
develop an acceptable system within the allotted time and budget.
9. There are different routes through the basic systems development phases. An appropriate route
is selected during the preliminary investigation phase. Typical routes include:
a. Modeldriven development techniques emphasize the drawing of models to help visualize
and analyze problems, define business requirements, and design information systems. Alternative
modeldriven strategies include:
(1) Structured analysis and design.
(2) Information engineering.
(3) Objectoriented analysis and design.
b. Rapid application development (RAD) techniques emphasize extensive user involvement in
the rapid and evolutionary construction of working prototypes of a system to accelerate the system
development process.
c. Commercial offtheshelf (COTS) techniques focus on the purchase and integration of a
software package or solution to support one or more business functions and information
systems.
d. The maintenance and reengineering route is intended to guide projects through the
operation and support stage of the life cycle.
10. Automated tools support all systems development phases.
a. Computeraided systems engineering (CASE) tools are software programs that automate
or support the drawing and analysis of system models and provide for the translation of
system models into application programs.
(1) A CASE repository is a system developer's database. It is a place where developers
can store system models, detailed description and specifications, and other products of
system development.
(2) Forward engineering requires the system analyst to draw system models, either from
scratch or from templates. The resulting models are subsequently transformed into
program code.
(3) Reverse engineering allows a CASE tool to read existing program code and
transform that code into a representative system model that can be edited and refined by
the systems analyst.
b. Application development environments (ADE's) are integrated software development tools
that provide all the facilities necessary to develop new application software with maximum speed and
quality.
c. Process management tools to help us document and manage a methodology and routes, its
deliverables, and quality management standards.
d. Project management tools help us plan system development activities (preferably using the
approved methodology), estimate and assign resources (including people and costs), schedule
activities and resources, monitoring progress against schedule and budget, control and modify
schedule and resources, and report project progress.
Chapter 4
1. A project is a (temporary) sequence of unique, complex, and connected activities having one
goal or purpose and that must be completed by a specific time, within budget, and according to
specification.
2. Project management is the process of scoping, planning, staffing, organizing, directing, and
controlling the development of an acceptable system at a minimum cost within a specified time
frame.
3. Process management is an ongoing activity that documents, manages the use of, and improves
an organization's chosen methodology (the “process”) for systems development. Process
management is concerned with the activities, deliverables, and quality standards to be applied
to all projects.
4. From a project management perspective, a project is considered a success if the resulting
information system is acceptable to the customer, the system was delivered “on time” and
“within budget,” and the system development process had a minimal impact on ongoing
business operations.
5. The Project Management Institute has created the “Project Management Body of Knowledge”
(PMBOK) for the education and certification of professional project managers. It addresses:
a. Project manager competencies.
b. Project management functions, which include:
i) Scoping v) Organizing
ii) Planning vi) Directing
iii) Estimating vii) Controlling
iv) Scheduling viii) Closing
c. Tools and techniques such as:
i) PERT charts, graphical network models that depict a project's tasks and the
relationships between those tasks.
ii) Gantt charts, simple horizontal bar charts that depict project tasks against a calendar.
d. Project management software.
6. Project management is a cross life cycle activity; that is, project management tasks that
overlap all the system development phases. A project management process is essential to
achieving CMM Level 2 maturity.
7. Joint project planning (JPP) is a strategy wherein all stakeholders in a project participate in a
onetothreeday project management workshop, the result of which is consensus agreement on
project scope, schedule, resources, and budget.
8. The tasks of project management include:
a. Negotiate scope. Scope defines the boundaries of a project and is included in the
statement of work, a narrative description of the work to be performed as part of a project.
b. Identify tasks. A work breakdown structure (Wbs) is a hierarchical decomposition of the
project into its tasks and subtasks. Some tasks represent the completion of milestone or the
completion of major deliverables during a project.
c. Estimate task durations. There are many techniques and tools for estimating task
durations.
d. Specify intertask dependencies. The start or completion of individual tasks may be
dependent on the start or completion of other tasks. These dependencies impact the
completion of any project.
i) Forward and reverse scheduling are two strategies for generating the preliminary
schedule. The former works forward from a project start date, while the latter works
backward from a project deadline.
e. Assign resources. The following resources may impact a project schedule: People,
services, facilities and equipment, supplies and materials, and money.
i) Such resources must be assigned to tasks to develop a schedule.
ii) Resource leveling is a strategy used to correct resource overallocations by some
combination of delaying or splitting tasks. Resource leveling requires knowledge of:
(1) The critical path – that sequence of dependent tasks that have the largest sum of
most likely durations. The critical path determines the earliest possible completion
date of the project.
(2) Slack time – the amount of delay that can be tolerated between the starting time
and completion time of a task without causing a delay in the completion date of the
entire project.
f. Direct the team effort. One of the most important dimensions of directing the team effort
is the supervision of people.
g. Monitoring and control progress. During the project, the project manager must monitor
project progress against the scope, schedule, and budget, and when necessary, make
adjustments scope, schedule, and resources.
i) Progress reporting is an essential control process that uses communication to keep a
project within scope, on time, and within budget.
ii) A complete project plan provides mechanisms and a process to manage requests for
changes to scope. This is called change management.
iii) Change management frequently requires a project manager to manage the
expectations of user management and users themselves. An expectations management
matrix is a ruledriven tool for helping management understand the dynamics and
impact of changing project parameters such as cost, schedule, scope, and quality.
iv) Schedule adjustments are required when a project's scope changes, or when other
factors drive schedule or budget out of the projected range.
h. Assess project results and experiences. This final activity involves soliciting feedback
from project team members (including customers) concerning their project experiences and
suggestions aimed at improving the project and process management of the organization.
Chapter 5
1. Formally, systems analysis is the dissection of a system into its component pieces. As a
problemsolving phase, it precedes systems design. With respect to information systems
development, systems analysis is the preliminary investigation of a proposed project, the study
and problem analysis of the existing systems, the requirements analysis of business requirements
for the new system, and the decision analysis for alternative solutions to fulfill the requirements.
2. The results of systems analysis are stored in a repository for use in later phases and projects.
3. There are several popular or emerging strategies for systems analysis. These techniques can be
used in combination with one another.
a. Modeldriven analysis techniques emphasize the drawing of pictorial system models
that represent either a current reality or a target vision of the system.
1) Structured analysis is a technique that focuses on modeling processes.
2) Information engineering is a technique that focuses on modeling data.
3) Objectoriented analysis is a technique that focuses on modeling objects that
encapsulate the concerns of data and processes that act on that data.
b. Accelerated analysis approaches emphasize the construction of working models of a
system in an effort to accelerate systems analysis.
1) Discovery prototyping is a technique that focuses on building smallscale, functional
subsystems to discover requirements.
2) Rapid architecture analysis attempts to automatically generate system models from
either prototypes or existing systems. The automatic generation of models requires
reverse engineering technology.
c. Both modeldriven and accelerated system analysis approaches are dependent on
requirements discovery techniques to identify or extract problems and requirements from
system owners and users.
1) Factfinding is the formal process of using research, interviews, questionnaires,
sampling, and other techniques to collect information.
2) Joint requirements planning (JRP) techniques use facilitated workshops to bring
together all interested parties and accelerate factfinding.
d. Business process redesign focuses on simplifying and streamlining fundamental
business processes before applying information technology to those processes.
4. Each phase of system analysis (preliminary investigation, problem analysis, requirements
analysis, and decision analysis) can be understood in the context of the information system
building blocks: DATA, PROCESS, and INTERFACES.
5. The preliminary phase determines the worthiness of the project and creates a plan to complete
those projects deemed worthy of a detailed study and analysis. To accomplish the preliminary
investigation phase, the systems analyst will work with the systems owners and users to:
(a) list problems, opportunities, and directives; (d) plan the project, and
(b) negotiate preliminary scope; (e) present the project to the business
(c) assess project worth; community.
The deliverable for the preliminary investigation phase is a project charter that must be approved by
system owners and/or a decisionmaking body, commonly referred to as the steering committee.
6. The purpose of the problem analysis phase is to answer the questions: Are the problems really
worth solving? And Is a new system really worth building? To answer these questions, the
problem analysis phase thoroughly analyzes the alleged problems and opportunities first
identified in the preliminary investigation phase. To complete the problem analysis phase, the
analyst will continue to work with the system owner, system users, and other IS management
and staff. The systems analyst and appropriate participants will:
(a) study the problem domain; (d) establish system improvement objectives
(b) thoroughly analyze problems and and constraints;
opportunities, (e) update the project plan; and
(c) optionally, analyze business processes; (f) present the findings and recommendations.
The deliverables for the problem analysis phase are the system improvement objectives.
7. The requirements analysis phase identifies what the new system is to do without the
consideration of technology; in other words, define the business requirements for a new system.
As in the preliminary investigation and problem analysis phases, the analyst actively works wih
system users and owners as well as other IS professionals. To complete the requirements
analysis phase, the analyst and appropriate participants will:
(a) define requirements; (c) trace and complete the requirements
(b) analyze functional requirements using statements;
system modeling and/or discovery (d) prioritize the requirements; and
prototyping; (e) update the project and scope.
The deliverable of the requirements analysis phase is the business requirements statement. Because
requirements are a moving target with no finalization, requirements analysis also includes an
ongoing task to manage changes to the requirements.
8. The purpose of the decision analysis phase is to transition the project from business concerns to
technical solutions by identifying, analyzing, and recommending a technical system solution. To
complete the decision analysis phase, the analyst and appropriate participants will:
(a) define candidate solutions;
(b) analyze candidate solutions for feasibility (technical, operational, economic, and schedule
feasibility);
(c) compare feasible candidate solutions to select one or more recommended solutions;
(d) update the project plan based on the recommended solution; and
(e) present and defend the target solution.
The deliverable of the decision analysis phase is the system proposal.
Chapter 6
1. System requirements define the services the system the system is to provide and prescribe
constraints for its operation. In documenting the system requirements for a new information
system, an analyst will likely identify dozens of unique requirements. To simplify the
presentation of the requirements and to make them more readable, understandable and
traceable, requirements are often categorized as functional versus nonfunctional.
2. For systems analysts to be successful, they must be skilled in problem analysis. This is the
ability to identify problems, understand the problems (including the causes and effects), and
understand any constraints that limit the solution. A popular tool used by development teams to
identify, analyze and solve problems is an Ishikawa diagram.
3. Effective fact finding techniques are crucial to the applications of systems analysis and design
methods during systems projects. Fact finding is performed during all phases of the systems
development life cycle. To support development activities, the analyst must collect facts about
end – users, the business, data and information resources, and information systems components.
4. Conducting business in an ethical manner is a required practice, and analysts need to be more
aware of the implications of not being ethical.
5. Fact – finding activities usually produce requirements that conflict with each other. This is
because requirements are solicited from many different sources and each person has his own
opinions and the desire to the functionality and features of the new system. Systems analysts
perform requirements analysis to discover and resolve the problems with the requirements and
reach agreement on any modifications to satisfy the stakeholders.
6. System requirements are usually documented in a formal way to communicate the requirements
to the key stakeholders of the system. This document usually serves as the contract between the
system owners and the development team on what is going to be provided in terms of a new
system.
7. Over the lifetime of the project it is very common for new requirements to emerge and existing
requirements to change once a requirements definition document has been approved.
Requirements management encompasses the policies, procedures, and processes that govern
how a change is handled.
8. There are seven fact – finding technique.
a. The sampling of existing documents and files can provide many facts and details with little
or no direct personal communication being necessary. The analyst should collect historical
documents, business operations manuals and forms, and information systems documents.
b. Research is an often – overlooked technique based on the study of other similar applications.
It now has become more convenient with the Internet and World Wide Web. Site visits are a
special form of research.
c. Observation is a fact – finding technique in which the analyst studies people doing their
jobs.
d. Questionnaires are used to collect similar facts from a larger number of individuals.
e. Interviews are the most popular but the most time consuming fact – finding technique.
When interviewing, the analyst meets individually with people to gather information.
1) When most people talk about communication skills they think of speaking and writing,
but the skills of listening may be the most important, especially during the interviewing
process.
2) Research has determined that of a person’s total feelings, only 7 percent are
communicated verbally (in words), 38 percent are communicated by the tone of voice
used, and 55 percent are communicated by facial and body expressions. If you only
listen to someone’s words, you are missing most of what they have to say! Experienced
systems analysts pay close attention to body language and proxemics.
f. Discovery prototyping is frequently applied to systems development projects, especially
when the development team is having problems defining system requirements. The
philosophy is that the users will recognize the requirements when they see them. It is
important that the prototype be developed quickly so it can be used during the development
process.
g. Many analysts find flaws with interviewing – separate interviews often lead to conflicting
facts, opinions and priorities. The end result is numerous follow – up interviews and / or
group meetings. For this reason, many organizations used the group work session known as
a joint requirements planning as a substitute for interviews.
1) Joint requirements planning sessions include a variety of participants and roles. Each
participant is expected to attend and actively participate for the entire duration of the
JRP session.
2) An effective JRP session involves extensive planning. Planning for a JRP session
involves three steps: selecting a location, selecting JRP participants and preparing an
agenda.
9. Because “time is money,” it is wise and practical for the system analyst to use a fact finding
strategy to maximize the value of time spent with the end – users.
10. Systems analysts should assemble or document the information they have gathered in an
understandable and meaningful way. Good systems analysts used techniques and tools that allow
them to clearly specify the system requirements.
a. Use cases describe the system functions from the perspective of external users and in a
manner and terminology they understand.
b. Many organizations have complex policies and decision – making rules that drive their
business processes. Decision tables are a popular tool in expressing and analyzing these
requirements.
c. Many organizations document their requirements in tabular form called a requirements
table.
Chapter 7
1. A model is a representation of reality. Models can be built for existing systems as a way to
better understand those systems or for proposed systems as a way to document business
requirements or technical designs.
a. Logical models document the business requirements to show what a system is or does. They
are implementation independent; that is, they depict the system independent of any technical
implementation. As such, logical models illustrate the essence of the system.
b. Physical models show not only what a system is or does, but also how the system is
physically and technically implemented. They are implementation dependent because they
reflect technology choices and the limitations of those technology choices.
2. Data modeling is a technique for organizing and documenting a system’s DATA. Data
modeling is sometimes called database modeling because a data model is usually implemented
as a database.
3. There are several notations for data modeling. The actual model is frequently called an entity
relationship diagram (ERD) because it depicts data in terms of the entities and relationships
described by the data.
4. An entity is something about which the business needs to store data. Classes of entities include:
persons, places, objects, events or concepts.
5. An entity instance is a single occurrence of an entity class.
6. Pieces of data we want to store about each instance of a given entity are called an attribute. An
attribute is a descriptive property or characteristic of the entity. Some attributes can be logically
grouped into super attributes called compound attributes.
7. When analyzing a system, we should define those values for an attribute that are legitimate or
that make business sense. The values for each attribute are defined in terms of three properties:
data type, domain and default.
a. The data type defines what class of data can be stored in that attribute.
b. The domain of an attribute defines what values an attribute can legitimately take on.
c. The default value for an attribute is the value that will be recorded if not specified by the
user.
8. Every entity must have an identifier or key. A key is an attribute, or a group of attributes, that
assumes a unique value for each entity instance.
a. Group of attributes that uniquely identifies an instance of an entity is called a concatenated
key.
b. A candidate key is a “candidate to become the primary identifier” of instances of an entity.
c. A primary key is the candidate key that will most commonly be used to uniquely identify a
single entity instance.
d. Any candidate key that is not selected to become the primary key is called an alternate key.
e. Sometimes, it is also necessary to identify a subset of entity instances as opposed to a single
instance. A sub – setting criteria is an attribute (or concatenated attribute) whose finite
values divide all entity instances into useful subsets.
9. A relationship is natural business association that exists between one or more entities. The
relationship may represent an event that links the entities or merely a logical affinity that exist
between the entities. All relationships are implicitly bidirectional, meaning they can be
interpreted in both directions.
10. Cardinality defines the minimum and maximum number of occurrences of one entity for a
single occurrence of the related entity. Because all relationships are bidirectional, cardinality
must be defined in both directions for every relationship.
11. The degree of a relationship is the number of entity classes that participate in the relationship.
Not all relationships are binary. Some relationships may be recursive relationships wherein the
relationship exists between different instances of the same entity. Relationships also exist
between more than two different entities, as in the case of a 3 – ary or ternary relationship.
12. An associative entity is an entity that inherits its primary key from more than one other entity
(parents). Each part of that concatenated key points to one and only one instance of each of the
connecting entities.
13. Foreign key is a primary key of one entity that is contributed to (duplicated in) another entity
to identify instances of a relationship. A foreign key (always in a child entity) always matches
the primary key (in a parent entity)
14. Non identifying relationships are those in which each of the participating entities has its own
independent primary key, of which none of the primary key attributes is shared. The entities in
a non – identifying relationship are referred to as strong or independent entities because neither
depends on any other entity for its identification. Identifying relationships are those in which the
parent entity contributes its primary key to become part of the primary key of the child entity.
The child entity of any identifying relationship is referred to as a weak entity because its
identification is dependent on the existence of the parent entity’s existence.
15. A nonspecific relationship (or many to many relationship) is one in which many instances of
one entity are associated with many instances of another entity. Such relationships are suitable
only for preliminary data models and should be resolved as quickly as possible.
16. Generalization is an approach that seeks to discover and exploit the commonalities between
entities. It is a technique wherein the attributes are grouped to form entity super types and
subtypes.
17. A logical data model is developed in the following stages:
a. Entities are discovered and defined.
b. A context data model is built. A context data model contains only business entities and
relationships identifies by the system owners and users.
c. A key – based data model is built. The key – based model eliminates nonspecific
relationships and adds associative entities. All entities in the model are given keys.
d. A fully attributed model is built. This model shows all the attributes to be stored in the
system.
e. A fully described model is built. Each attribute is defined in the dictionary and described in
terms of properties such as domain and security.
f. The completed data model is then analyzed for adapt – ability and flexibility through a
process called normalization. The final analyzed model is referred to as third normal form
data model.
18. A logical data model does not communicate data requirements on a business operating location
basis. Systems analysts have found it useful to define these requirements in the form of a data –
to – location – CRUD matrix.