MIS 3360 Exam 2

DFD Rules- Data Store

-Data cannot move directly from one data store to another data store. Data must be moved by a process - Data cannot move directly from an outside source to a data store. Data must be moved by a process that receives data from the source and places the data into the data store - Data cannot move directly to an outside sink from a data store. Data must be moved by a process - A data store has a noun phrase label

Activity Diagram Purpose

-Depicts the flow of control from activity to activity -help in "use case" analysis to understand what actions need to take place -Help in identifying extensions to a "use case" -Model work flow and business processes -Model the sequential and concurrent steps in a computation process

Guidelines for Defining Entity Types

-Include a statement of the unique characteristic(s) for each instance of the entity type - Clarify what entity instances are included and not included in the entity type - Often includes a description of when an instance of the entity type is created and deleted - Some definitions must specify when an instance might change into an instance of another entity type - Some definitions must specify what history is to be kept about entity instances

Gap analysis involves examining DFDs for

-Redundant data flows -Data that are captured but not used - Data updated identically in more than one location - Inefficiencies

Elements of Activity Diagrams:

-Swimlanes -Start -Branch -Activity -Fork -Merge -Join -End

Types of business rules

-Total specialization -Partial specialization -Disjoint rule -Overlap rule

Types of BPMN Gateways

-XOR -AND -OR

Naming and defining relationships

-a relationship name is a descriptive verb phrase -avoid vague names -ex: Assigned_to, not assignment

denormalization tradeoffs

-can increase the chance of errors and inconsistencies that normalization avoided

Selection Rules for an Identifier

-choose a candidate key that will not change its value -choose a candidate key will never be null -avoid using intelligent keys (e.g Part Key with location; initials-hard to guarantee uniqueness) -Consider substituting single value surrogate (generated by the system) keys for large composite keys (combination of attributes)

all relations have a primary key

-ensures that rows are unique -may involve a single attribute or be composed of multiple attributes

DFD Rules

1. Process 2. Data Store 3. Source/Sink 4. DataFlow

General steps in database design

1. logical database modeling & design 2. physical database design

objectives for data type selection

1. minimize storage space 2. represent all possible values of the field 3. improve data integrity of the field 4. support all data manipulations desired

Viewer integration problems

1. synonyms 2. homonyms 3. transitive dependency 4. class/subclass relationships

properties of relations

1.entries in cells are simple (single value) 2. entries in a given column are form the same set of values 3.each row in unique (non-null primary key) 4. columns can be interchanged/stored in any sequence 5. rows can be interchanged/stored in any sequence

Normal forms

1NF, 2NF, 3NF

Fork

Beginning of parallel activities (horizontal line with 2 arrows coming of it)

E-R model is expressed in terms of

Data Entities-in the business environment Relationships-or associations among those entities Attributes- or properties of both the entities and their relationships

System Boundary

Includes all relevant use cases -dividing line between the system and its environment -use cases inside -actors outside

Rules

Specifies which actions are to be followed for a set of conditions

Action Stubs

The actions that result for a set of conditions

End

The end of a process (a filled in circle that has another circle around it)

Sequence Diagram- Lifeline

Time during which an object exists

Degree

Unary, Binary, Ternary, or higher (n-ary)

Process

Work or actions performed on data (inside the system)

Query

accesses (but does not alter) the state of an object -has no side effects -ex; cal_age(), get_year()

Controlling data integrity

accurate data are essential for compliance with national and international regulations

action

action taken when the operation is triggered

Activity

action that must take place for a process to be completed

hashed

address for each row is determined using an algorithm

Binary 1:N Relationship

adds the primary key attributes of the entity of the 1 side of the relationship as a foreign key in the relation that is on the many (N) side of the relationship

AND

all of the paths that follow the gateway can be followed in parallel

update

alters the state of an object ex: promote_student() would change the student object's state (value of the year attribute increases) ex: register_for(course) establishes a connection from a student object to a specific course object

Foreign Key (FK)

an FK is an attribute that appears as a on-primary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation -must satisfy the Referential Integrity Constraint

Relationship

an association between the instances of one or more entity types that is of interest to the organization -labeled with verb phrases

class-scope operation

applies to a class rather than an object instance (ex: avg_gpa() for all instances of the student class)

Synchronous message

caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself

concrete class

class that can have direct instances

abstract class

class that have no direct instances but whose descendants may have direct instances (similar to toal specialization)

referential integrity

constraint that specifies that the value/existence of an attribute in one relation depends on the value/existence of the same attribute in another relation

domains

constraints on valid values for attributes

Supertype/subtype

create a relation for the superclass, which contains the primary relation key and all nonkey attributes in common with all subclasses, plus create a separate relation for each subclass with the same primary key

constructor

creates a new instance of a class -available to all classes -not explicitly shown in a class diagram -ex: create_student() creates a new instance of student and initialized its state

even

data manipulation operation that initiates the operation

<<derived>>

derived attribute (calculations shown near the related object class)

overlapping

descendant may be from more than one of the subclasses

disjoint

descendant may not be from more than one subclass

Stereotype

designation about an attribute in a class diagram

Each regular _____ is transformed into a ______

entity, relation

range control

limits the range of values that can be entered into a field

Cardinality- many

maximum cardinality >1

Cardinality- Fixed number (e.g 4)

maximum cardinality=n

Class/subclass relationships

may be hidden resolve: create class/subclass relations

unary M:N relationship

model the entity type as a relationship -create a separate relation to represent the M:N relationship -the primary key of the new relation is a composite key that consists of two attributes that both take their values from the same primary key

association role

name given to the end of an association where it connects to a class ex: manager -use of role names is optional

entity name

name of entity being accessed or modified

Shorthand notation for a relation's structure

name of the relation (all caps) followed by the names of the attributes in the relation -primary key underlined

physical database design

prescribes the technical specifications for data storage in databases

data integrity controls

preventive measures that improve data quality -default value -range control -referential integrity -null value

<<PK>>

primary key

normalization

process of converting complex data structures into data structures characterized by simplicity, non-redundancy, and minimal maintenance

denormalization

process of splitting/combining normalized relations into physical tables -based on affinity of use of rows and fields -optimizes certain data processing activities at the expense of others

Attribute

property or characteristic of an entity that is of interest to the organization

Packaged data models

provide generic models that can be customized for a particular organization's business rules

Asynchronous message

sender does not have to wait for the recipient to handle the message

multiple key retrieval

sequential: possible, but requires scanning whole file indexed: very fast with multiple indexes hashed: not possible

sequential retrieval on primarykey

sequential: very fast indexed:moderately fast hashed:impractical

random retrieval on primary key

sequential:impractical indexed:moderately fast hashed: very fast

domain

set of all data types and values that an attribute can assume Advantages -verify that the values for an attribute are valid -ensure that various data manipulation operations are logical -help conserve effort in describing attribute characteristics

relational database

set of tables that are related by foreign keys referencing primary keys

purpose of conceptual data modeling

show as many rules about the meaning and interrelationships among data as possible

Collaboration diagrams

show relationships among objects

Generic form

shows all possible sequences of interactions. corresponding to all scenarios of a use case

Instance form

shows the sequence for only one scenario

flow

shows the sequence of action in a process

Business process

standard method for accomplishing a particular task necessary for an organization to function

User rule

statement of the business rule to be enforced by the trigger

data type

storage format for each attribute from the logical data model -minimize storage -maximize data quality

Subtype

subgrouping of the entities in an entity type -meaningful to the organization -shares common attributes or relationships distinct from other subgroupings

file organization

technique for physically arranging the records of a file

industry-specific data models

that are designed to be used by organizations within specific industries

Degree

the number of entity types that participate in a relationship

synonyms

two different names used for the same attribute resolve: obtain agreement from users on a single standardized name

Abstract use case

type of use case that is initiated by another use case instead of by an actor

entity integrity

unique, non-null identifiers

the value of the primary key must _____ each row in the relation

uniquely identify

Interaction Diagrams

used to show interactions among objects for a particular use case

default value

value that a field will assume unless an explicit value is entered for that field

DFDs of current logical system compared with DFDs of new logical system can show...

which processes need to be added or revised

total specialization

(double line) each entity instance of the supertype must be a member of some subtype in the relationship

disjoint rule

(letter d) if an entity instance of the supertype is a member of one subtype, it cannot simultaneously be a member of any other subtype

overlap rule

(letter o) an entity instance can simultaneously be a member of two or more subtypes

Entity-relationship (E-R) diagram

(or UML class diagram) -entities (or classes)- categories of data, represented as rectangles -relationship (or associations)- lines between the entities

partial specialization

(single line) an entity instance of the supertype does not have to belong to any subtype, and may or may not be an instance of one of the subtypes

DFD Rules- Data flow

- A data flow has only one direction of flow between symbols. It may flow in both directions between a process and a data store to show a read before an update. The latter is usually indicated, however by two separate arrows because the happen at different times - A fork in a data flow means that exactly the same data goes from a common location to two or more different processes, data stores, or sources/sinks (this usually indicates different copies of the same data goingt to different locations - a join in a data flow means that exactly the same data come from any of two or more different processes, data stores, or sources/sinks to a common location - A data flow cannot go directly back to the same process it leaves. There must be at least one other process that handles the data flow, produces some other data flow, and returns the original data flow to the beginning process - A data flow to a data store means update (delete or change) - A data flow from a data store means retrieve or use - A data flow has a noun phrase label. More than one data flow noun phrase can appear on a single arrow as long as all of the flows on the same arrow move together as one package

DFD Rules- Source/Sink

- Data cannot move directly from a source to a sink. it must be moved by a process if the data are of any concern to our system. Otherwise, the data flow is not shown on the DFD - A source/sink has a noun phrase label

Written Use Cases

- Document containing detailed specifications for a use case - Contents can be written as simple text or in a specifies format - Step-by-step description of what must occur in a successful use case

Level

- Refers to degree of detail in the use case description -Suggested levels 1. White- as seen from clouds 2. Kite- "birds-eye view" 3. Blue- sea-level view 4. Fish- below sea-level 5. Black- bottom of the sea

First Normal Form (1NF)

-an attribute value in a relation's row must be a single value from the domain -each relation must be able to be identified by a primary key- i.e. each row is unique (no 2 rows can be identical) -all relations are in 1NF

security controls

-code(encrypt)the files data -require data file users to login with user names and passwords, and impose limitations on file activities/users/data -prohibit users from directly manipulating dat, forcing programs and users to work with a copy of the data they need (original version will change only after updates have been checked for validity)

types of operations

-constructor -query -update

Well-structured relation

-contains a minimum amount of redundancy -allows users to insert, modify, and delete rows, without errors or inconsistencies

logical database modeling & design

-describes data using notation corresponding to the data organization used by a database management system -most common: relational database model

physical database design

-designing fields -designing physical tables -arranging table rows -designing controls for files

Benefits of Packaged data models

-dramatically reduced implementation times and costs - starting point for asking requirements questions - higher-quality models - represents "best practice" data modeling techniques and data model components whose quality often exceeds that which can be achieved by internal development teams, given typical organizational pressures

Binary/Unary 1:1 relationship

-either add the primary key of A as a foreign key of B -or add the primary key of B as a foreign key of A -or do both of the above

basic types of business rules

-entity integrity -referential integrity constraints -domains -triggering operations

Relationship definitions

-explain any optional participation -explain the reason for any explicitly maximum cardinality other than many -explain any restrictions on participation in the relationship -explain the extent of history that is kept in the relationship -explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance

M:N relationship

-given a binary M:N relationship between two entities (A and B) - create a separate relation C -the primary key of C is a composite key consisting of the primary keys of A and B -include any non primary key attributes associated with the M:N relationship in relation C

Entity-relationship diagram (E-R diagram)

-graphical representation of an E-R model -Purpose: to capture the richest possible understanding of the meaning of the data necessary for an information system or organization

DFD Rules- process

-no process can have only outputs. it is making data from nothing (a miracle). If an object has only outputs, then it must be a source -No process can have only inputs (a black hold). If an object has only inputs, then it must be a sink -A process has a verb phrase label

physical database design requirements

-normalized relations -definitions of each attribute -descriptions of where and when data are used, entered, retrieved, deleted, and updated -expectations/requirements for response time and data integrity -descriptions of the technologies used for implementing the files and database

file backup controls

-periodically make a backup copy of a file -store a copy of each change to a file in a transaction log or audit trail -store a copy of each row before or after it is changed

implementing controls on each file enables

-protection from failure/data loss -security from unauthorized use

types of table partitioning(oracle)

-range partitioning -hash partitioning -composite partioning *each partition is stored in a separate contiguous section of disk space (tablespace)

designing physical tables

-relational database -physical table -denormalization

physical database design: database tables

-results from conversion of relations -represents coding the definitions of the database -written in structured query language (SQL)

Activity Diagrams

-show the conditional logic for the sequence of system activities needed to accomplish a business process -clearly show parallel and alternative behaviors -can be used to show the logic of a use case

specialized notation

-specialized event notation (such as from message, or at particular time) -specialized flow notation (sequence, default, or message flow)

Functional Dependencies (FDs)

-specify a relationship between attributes in a relation

Guidlines for defining attributes

-states what the attribute is and possible why it is important -should make it clear what is included and what is not included -contains any aliases or alternative names -states the source of values for the attribute

Second Normal Form (2NF)

-the relation in is 1NF -there are no Partial Dependencies -a partial dependency exists a) if the relation has a composite primary key and b) if attributes in the relation depend only on part of the primary key and not the complete primary key

Third Normal Form (3NF)

-the relation is in 2NF -There are no Transitive Dependencies -A transitive dependency exists when a non-primary key attribute depends on other non-primary key attributes rather than depending upon the primary key

common situations for denormalization

-two entities with a one-to-one relationship -associative entity (many-to-many relationship with non key attributes) -reference data

Decision Table Procedure

1. Name conditions and values each condition can assume 2. Name all possible actions that can occur 3. List all possible rules 4. Define actions for each rule 5. Simplify the decision table

Transforming E-R Diagrams into Relations

1. Represent Entities 2. Represent relationships 3. Normalize the relations 4. Merge the relations

conceptual data modeling process

1. develop a data model for the current system (if system already exists) 2.develop a new conceptual data model that includes all requirements of the new system 3. in the design stage, the conceptual data model is translated into a physical design 4. project repository links all design and data modeling steps performed during SDLC

logical database modeling and design

1. develop a logical data model 2. combine data requirements 3. translate 4. compare

Properties of relations

1. entries in cells are simple 2. entries in columns are from the same set of values 3. each row is unique 4. the sequence of columns can be interchanged without changing the meaning/use of the relation 5. the rows may be interchanged/stored in any sequence

file organization goals

1. fast data retrieval 2. high throughput for processing transactions 3. efficient use of storage space 4. protection form failures or data loss 5. minimal need for reorganization 6. accommodation of growth 7. security from unauthorized use

Requirements Determination Questions for Data Modeling

1. what are the subjects/objects of the business? 2. What unique characteristic [or characteristic] distinguishes each object from other objects of the same type? 3. What characteristics describe each object? 4. How do you use these data? 5. Over what period of time are you interested in these data? 6.Are all instances of each object the same? 7.What events occur that imply associations among various objects? 8. Is each activity or event always handled the same way or are there special circumstances?

data type

A coding scheme recognized by system software for representing organizational data.

Branch

A condition whose results provide transitions to different activity paths (diamond)

Indifferent Condition

A condition whose value does not affect which actions are taken for two or more rules. E.g. Hours worked for Salaried Employees

Repeating group

A set of two or more multivalued attributes that are logically related.

ternary relationship

A simultaneous relationship among the instances of three entity types.

Other Written Use Case Information- Stakeholders

Any group/individual with an interest in the function of the use case

Extend Relationship

Association between two use cases where one adds new behaviors/actions to the other -extends use case by adding new behavior/actions -specialized use case extends the generalized use case -arrow from use case X to use case Y indicates that X is a special case behavior of the more general process Y <<extend>>

Include Relationship

Association between two use cases where one uses the functionality contained in the other -indicates a use case that is invoked by another -links to general purpose functions, used by many other use cases -arrow from use case X to use Y indicates that X always involves at least one Y (X has a subtask Y) <<include>>

Business Process Modeling Notation (BPMN)

Business process modeling approach established by the object modeling group

Swimlanes

Columns representing different organizational units of the system (vertical lines)

Other Written Use Case Information- Precondition

Condition that must be satisfied in order to execute the use case

Data store

Data at rest (inside the system), which may take the form of different physical representations

Data flow

Data in motion, moving from one place in a system to another

Structuring system data requirements

Definition/structure/relationships/within the data -entity-relationship diagrams -class diagrams

Use case

Depiction of a system's behavior/functionality under various conditions as the system responds to requests from users

Connections

Depicts a usage relationship between an actor and use case -does not indicate data flow -actors connected to use cases with lines (not arrows) -use cases connected to each other with arrows

Use Case Diagram

Depicts system behavior along with the key actors that interact with the system

Other Written Use Case Information- Main success scenario

Description of the sequence of interactions between an actor and a use case during the use case execution

Other Written Use Case Information- Title

Descriptive name, matches name in use case diagram

Other Written Use Case Information- Extensions

Detailed descriptions of how errors are handled

Join

End of parallel activities (horizontal line with 2 arrows coming into it)

Basic Notation

Event, Activity, Gateway, Flow

Other Written Use Case Information- Trigger

Event/action that initiates a use case

Use Case Relationships

Extend Relationship & Include Relationship

Actor

External entity that interacts with the system -represents a single role, not a specific user -may represent many users -most actors represent user roles, but some actors can be external systems

Source/sink

External entity that is the origin or destination of data (outside the system)

Representing Objects and Classes- Operation

Function/service that is provided by all the instances of a class to invoke behavior in an object by passing a message

DFDs in BPR

Help show inefficiencies in the existing system

Structuring System Process Requirements

How/where/when data is used/changed -DFDs -use case diagrams -activity diagrams -sequence diagrams -BPMN

Representing Objects and Classes- Object Class (class)

Logical grouping of objects that have the same (or similar) attributes, relationships, and behaviors (methods)

Decision Table

Matrix representation of the logic of a decision which specifies the possible conditions for the decision and the resulting actions. -Best used for complicated decision logic -Example given is a payroll system in a organization

Sequence Diagram- Message

Means by which objects communicate with each other

Other Written Use Case Information- Minimal Guarantee

Outputs that can be expected if the service attempt fails

Other Written Use Case Information- Success Guarantee

Outputs that can be expected if the service succeeds

gap analysis

Process of discovering discrepancies between two or more sets of DFDs or within a single DFD

Logical database design: Normalized relations

Relation: Named, 2-dimensional table of data (does not equal computer files -Accounts for every data element on a system input/output

Types of interaction diagrams

Sequence Diagrams & Collaboration Diagrams

storage space

Sequential: no wasted space indexed:no wasted space for data, but extra space for index hashed: extra space may be needed to allow for addition and deletion of records

Sequence Diagrams

Show explicit sequencing of messages. Depict the interactions among objects during a certain period of time. May be presented in either generic form or instance form

Representing Objects and Classes- Class Diagram

Shows the static structure of object classes, their internal structure, and the relationships in which they participate

Types of Messages

Synchronous message, Simple message, Asynchronous message

Representing Objects and Classes- Encapsulation

Technique of hiding the internal implementation details of an object from its external view

Start

The beginning of a process (filled in circle)

Condition Stubs

The conditions relevant to a decision

Sequence Diagram- Activation

Time period during which an object performs an operation

Event

Trigger that initiates the start of a process

Other Written Use Case Information- Primary Actor

Usually a user role

commonly used data types in oracle

VARCHAR2 CHAR LONG NUMBER DATE BLOB

Merge

Where different paths converge (diamond)

Entity (set)

a person, place, object, event or concept in the user environment about which data is to be maintained

binary relationship

a relationship between instances of two entity types -most common type of relationship encountered in data modeling

unary relationship

a relationship between the instances of one entity type - also called a recursive relationship

An entity type name should be:

a singular noun (STUDENT, not STUDENTS) Descriptive and specific to the organization (PURCHASE ORDER or CUSTOMER ORDER, not ORDER for both) Concise -Event entity type should be named for the result of the event, not the activity or process of the even (ASSIGNMENT for the event of a manager assigning an employee to a project)

complete

all subclasses have been specified (not the same as total specialization)

Composite attribute

an attribute that has meaningful components parts (e.g. address (street, city, state, zip)

Optional attribute

an attribute that may not have a value for every entity instance (symbolized by normal text)

required attribute

an attribute that must have a value for ever entity instance (symbolized by bold text)

Derived attribute

an attribute whose value can be computed from related attribute values (e.g. [age] calculated from DOB)

universal data models

are templates for -core subject areas (customers, products, accounts, documents) -and/or core business functions (purchasing, accounting, receiving)

file organization

arranging related records in secondary memory for storage, retrieval, and updates

Trigger

assertion/rule that governs the validity of data manipulation operations such as insert, update and delete Includes following components: user rule event entity name condition action

Associative class

association that has attributes/operations of its own or that participates in relationships with other classes -analogous to associative entities in E-R diagrams

OR

atleast one path out of the gateway must be followed, but all path that leave the gateway can be followed

candidate key

attribute (or combination of attributes) that uniquely identifies each instance of an entity type -some entities may have multiple candidate keys -identifier -identifiers are symbolized by a solid underline

class-scope attribute

attribute of a class that specifies a value common to an entity class, rather than a specific value for an instance

Determinant

attribute that determines other attributes

primary key

attribute whose value is unique across all occurrences of a relation

Activity

behavior that an object carries out while in a particular state (rounded rectangle)

Attribute types

candidate key multivalued attribute

Identifier

candidate key that has been selected as the unique, identifying characteristic for an entity type

partitioning

capability to split a table into separate sections

basic decisions

choosing data types controlling data integrity

Entity type (entity)

collection of entities that share common properties/characteristics

condition

condition that causes the operation to be triggered

weak entity

create a relation with a composite primary key (which includes the primary key of the entity on which this weak entity depends) and nonkey attributes

binary or unary M:N relationship or associative entity with additional keys

create a relation with a composite primary key using the primary keys of the related entities and additional primary key attributes associated with the relationship or associative entity, plus any nonkey attributes of the relationship or associative entity

binary or unary M:N relationship

create a relation with a composite primary key using the primary keys of the related entities, plus any nonkey attributes associative entity of the relationship or associative entity

regular entity

create a relation with primary key and non-key attributes

binary or unary M:N relationship or associative entity with its own key

create a relation with the primary key associated with the relationship or associative entity, plus any nonkey attributes of the relationship or associative entity and the primary keys of the related entities

gateway

decision point

abstract operation

defines the form/protocol of the operation, but not its implementation

conceptual data model

detailed model that captures the overall structure of organizational data, independent of any database management system (DBMS) or other implementation considerations -first-cut model (starting point to building a database) -typically occurs in parallel with other requirements analysis and structuring activities during systems analysis

Entity-relationship data model (E-R model)

detailed, logical representation of the entities, associations and data elements for an organization or business area

Referential Integrity Constraint

each foreign key value must match a primary key value in another relation, OR the foreign key value must be null

associative entity

entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances -often represents a relationship that the data modeler chooses to model as an entity type -relationships MUST be modeled as associative entities when they have additional relationships with entities

Representing Objects and classes- Object

entity with a well-defined role in an application domain with state, behavior, and identity characteristics (single occurrence of a class)

XOR

exclusive OR gateway; only one of the paths that exit the gateway can be followed

pointer

field of data that can be used to locate a related field/row of data

Develop a logical data model

for each known user interface for the application

recursive foreign key

foreign key in a relation that references the primary key values of the same relation

combine data requirements

from all user interfaces into a single consolidated logical data model (view integration)

transitive dependency

functional dependency between non-primary attributes resolve: create 2 relations as a foreign key

supertype

generic entity type that has a relationship with one or more subtypes

stored data structure

grouping logical database model attributes into physical records

The _____ of the entity type becomes the ______ of the corresponding relation

identifier, primary key

Generalization

implemented via superclass/subclasses analogous to supertypes/subtypes in E-R diagrams -Overlapping, Disjoint, Complete, Incomplete

<<dynamic>>

indicates an object may change subtypes

multiplicity

indicates how many objects participate in a given relationship -0...10 means minimum 0, maximum 10 -1, 2 means either 1 or 2 - * means infinite upper bound -analogous to cardinality in E-R diagrams

multivalued attribute

may take on more than one value for each entity instance (ex: {skill})

Cardinality-optional

minimum cardinality =0

Cardinality- mandatory

minimum cardinality >0

physical table

named set of rows and columns that specifies the fields in each row of the table -may or may not correspond to one relation -design of physical tables aims for efficient use of secondary storage and data processing speed

physical file

named set of table rows stored in a contiguous section of secondary memory

the primary key should be _____ - i.e. no attribute in the primary key can be deleted without destroying its unique identification

non-redundant

attribute names should be

nouns unique standard format distinguishable from similar attributes of different entity types

triggering operations

other business rules that protect the validity of attribute values

composition

part object that belongs to just one whole object and that lives and dies with the whole

aggregation

part-of relationship between a component object and an aggregate object

Entities

person, place, object, event, or concept in the user environment about which the organization wishes to maintain data ex: EMPLOYEE, PRODUCT, REGISTRATION, ACCOUNT, COURSE, WAREHOUSE

Binary 1:N relationship

place the primary key of either entity in the relation for the other entity or do this for both entities

Binary or unary 1:1 relationship

place the primary key of either entity in the relation for the other entity or do this for both entities

Association

relationship among instances of object classes -parallels the relationship element of an E-R model -Degree

Sequence Diagram- Objects

represented by boxes at top of diagram

Relational Database Model

represents data as a set of related tables (relations) -Relation: named, 2-dimensional table of data -set of named columns (attributes) -arbitrary number of unnamed rows (records) -primary key(identifier)

indexed

rows are stored either sequentially or non-sequentially, and an index is created that allows software to locate individual rows

sequential

rows in a file are stored in sequence according to a primary key value

referential integrity constraints

rules governing relationships between entity types

polymorphism

same operation may apply to two or more classes in different ways

storage media

selecting media and structures for data storage to make access more efficient

discriminator

shows which property of an object class is being abstracted (ex: residency)

homonyms

single attribute name is used for 2+ different attributes resolve: create new attribute names

Entity instance (data)

single occurrence of an entity type

entity instance (instance)

single occurrence of an entity type

field

smallest unit of named application data recognized by system software

incomplete

some additional subclasses are not in the model

null value

special field value that indicates that the value for the field is missing or otherwise unknown

Business rules

specifications that preserve the integrity of the logical data model -captured during requirements determination -stored in CASE repository as they are documented -implemented when creating the physical databases

Translate

the conceptual data model into normalized data requirements

compare

the consolidated logical data model with the translated model to produce a final logical data model

Unary 1:N relationship

the entity type is modeled as a relation -the primary key of that relation is the same as that of the entity type -a foreign key is added to the relation that references the primary key values -recursive foreign key

cardinality

the number of instances of an entity that can/must be associated with an entity

normalization

the process of converting complex data structures into simple, stable data structures

Decompose

the relation into new relations using determinants

set of entries about data objects

to be stored in repository, project dictionary, or data modeling software -repository links data, process, and logic models of an information system -data elements included in the data flow diagram (DFD) must appear in the related data model and vice versa -each data store in a process model must relate to business objects represented in the data model

simple message

transfers control from the sender to the recipient without describing the details of the communication