29
Data Models Data model A formal way of representing the data that are used and created by a business system Shows the people, places and things about which data is captured and the relationships among them. Logical data model Shows the organization of data without indicating how it is stored, created, or manipulated.

Systems Design Part 3

Embed Size (px)

DESCRIPTION

powerpoint about system design and analysis

Citation preview

Page 1: Systems Design Part 3

Data Models

Data model A formal way of representing the data that are used and created by a business systemShows the people, places and things about which data is captured and the relationships among them.

Logical data model Shows the organization of data without indicating how it is

stored, created, or manipulated.

Page 2: Systems Design Part 3

Entity-Relationship Diagram(ERD)

• A model that shows the logical relationships and interaction among system entities– Entity is a person, place, thing, or event for which

data is collected and maintained.• Provides an overall view of the system and a

blueprint for creating the physical data structures

Page 3: Systems Design Part 3

Avicenna System Analysis and Design System Design 3

Entity-Relationship Diagram• Representing entities– we represent an entity by a named rectangle– use a singular noun, or adjective + noun– refer to one instance in naming

PART-TIMEEMPLOYEECUSTOMER

Page 4: Systems Design Part 3

Avicenna System Analysis and Design System Design 4

Entity-Relationship Diagram

• Relationship– is an association between two entities– relationships should have active verb names– often recognised by a verb or "entity + verb + entity"

e.g. CUSTOMER places ORDERDOCTOR treats PATIENT

– relationships capture the "business rules“ in the system– relationships should go in both directions– Unlike Data Flow Diagrams, ERDs depict relationships, not data or

information flows

Page 5: Systems Design Part 3

5

Entity-Relationship Diagrams

MIS FinanceMarketing

John DouglasJuan Dela CruzJohn Santosemploys

employsemploys

DEPARTMENT EMPLOYEEemploysemploys

Page 6: Systems Design Part 3

Avicenna System Analysis and Design System Design 6

Types of Relationships

– One-to-one relationship (1:1): exist when only one instance in the first entity occurs for only one instance in the second entity

Page 7: Systems Design Part 3

7

Types of Relationships– One-to-many relati

onship (1:M): exist when one instance of the first entity can relate to many instances of the second entity, but each instance of the second entity can associate with only one instance of the first entity

Page 8: Systems Design Part 3

Avicenna System Analysis and Design System Design 8

Types of Relationships

– Many-to-many relationship (M:N): exists when one instance of the first entity can relate to many instances of the second entity and one instance of the second entity can relate to many instances of the first entity.

Page 9: Systems Design Part 3

9

M:N relationship• This relationship is

hard to represent physically so we solve this problem by creating two (1:M) relationships.• The event or

transaction that links the two entities can be considered a third entity, called associative entity.

Associative Entity

Page 10: Systems Design Part 3

SALES REP

serves

CUSTOMER

ORDER WAREHOUSE

lists

ITEMS

stores

ORDER LINE

1

1

M

M

places

1

M

M

N

associative entity

Page 11: Systems Design Part 3

Avicenna System Analysis and Design System Design 11

Cardinality in relationships

– The cardinality describes the numeric relationship between two entities and shows how instances of one entity relate to instances of another entity.• For example consider the relationship CUSTOMER

places ORDER. One customer can have one order, many orders, or none, but each order must have one and only one customer.

– An analyst can model this interaction by adding cardinality notation, which uses special symbols to represent the relationship.

Page 12: Systems Design Part 3

Avicenna System Analysis and Design System Design 12

Cardinality

– Crow’s foot notation: It is called crow's foot notation because of the shapes, which include circles, bars, and symbols, that indicate various possibilities. A single bar indicates one, a double bar indicates one and only one, a circle indicates zero, and a crow's foot indicates many.

Page 13: Systems Design Part 3

Avicenna System Analysis and Design System Design 13

Cardinality

Crow's foot notation is a common method of indicating cardinality. The four examples show how you can use various symbols to describe the relationships between entities.

Page 14: Systems Design Part 3

Avicenna System Analysis and Design System Design 14

CARDINALITY

In the first example, one and only one CUSTOMER can place anywhere from zero to many of the ORDER entity. In the second example, one and only one ORDER can include one ITEM ORDERED or many. In the third example, one and only one EMPLOYEE can have one SPOUSE or none. In the fourth example, one EMPLOYEE, or many employees, or none, can be assigned to one PROJECT, or many projects, or none.

Page 15: Systems Design Part 3

ADVISER

advises STUDENT

takes

COURSE

1

M

M

N

Page 16: Systems Design Part 3

GRADECOURSE

STUDENTADVISER ADVISES

RECEIVES

SHOWSassociative entity

Page 17: Systems Design Part 3

Relational Models

• Physical representation of the database• Actual database tables will be modeled from

the ERD

Page 18: Systems Design Part 3

Avicenna System Analysis and Design System Design 18

Data Design Terminologies• Table or file: A set of related records is grouped into a table,

which stores data about a specific entity. Tables are shown as two-dimensional structures that consist of vertical columns representing fields and horizontal rows representing records.

• Field: A single characteristic or fact about an entity. A field, or attribute, is the smallest piece of data that has meaning within an information system. For example, a Social Security number or company name could be examples of a field. The terms, data element and field, are used interchangeably.

Page 19: Systems Design Part 3

Avicenna System Analysis and Design System Design 19

Data Design Terminologies

• Common field: A common field is an attribute that appears in more than one entity. Common fields can be used to link entities in various types of relationships.

• Record: also called a tuple, is a set of related fields that describes one entity instance, or member of an entity, such as one customer, one order, or one product. A record might have one or dozens of fields, depending on what information is needed.

Page 20: Systems Design Part 3

Avicenna System Analysis and Design System Design 20

Data Design Terminologies

• Key Fields– Key fields are used during the systems design

phase to organize, access, and maintain data structures. The four types of key fields are primary keys, candidate keys, foreign keys, and secondary keys.

Page 21: Systems Design Part 3

Avicenna System Analysis and Design System Design 21

Data Design Terminology• Key Fields

– Primary key: A primary key is a field or combination of fields that uniquely identifies a particular member of an entity. An identifier may be ‘artificial,’ such as creating an ID number. For example, in a student table the student number is a unique primary key because no two students can have the same student number. That key also is minimal because it contains no information beyond what is needed to identify the student.

– Sometimes it is necessary for a primary key to consist of combination of fields. In that case, the primary key is called a combination key, composite key, concatenated key, or multi-valued key. For example, if a student registers for three courses, his or her student number will appear in three records so its no more valid as a primary key. So in the registration file, neither the student number nor the course ID is unique, to identify a specific student in a specific course, the primary key must be a combination of student number and course ID

Page 22: Systems Design Part 3

Avicenna System Analysis and Design System Design 22

Data Design Terminologies

Supplier Name Supplier Address SupplierTel. No.

SupCon

Ahmad 115 zeriab St +962/7563025 Ali

Ali & sons 12 King Hussien St

020-8… ...

Bella Sonic Lake Industrial Estate

+962/7999663 ...

Supplier Number

1463

3621

2327

6762 … 3 Lot’s Corner ... ...

Columns

Attribute Names

Primary Key

Record

Field

Page 23: Systems Design Part 3

Avicenna System Analysis and Design System Design 23

• Key Fields– Candidate key: Sometimes it is possible to have a choice of

fields or field combinations to use as the primary key. Any field that could serve as a primary key is called a candidate key. For example, if every employee has a unique employee number, then you could use either the employee number or the Social Security number as a primary key. • nonkey field: Any field that is not a primary key or a candidate key

is called a nonkey field.

Data Design Terminologies

Page 24: Systems Design Part 3

Avicenna System Analysis and Design System Design 24

Data Design Terminologies• Key Fields– Foreign key: A foreign key is a field in one table that must

match a primary key value in another table in order to establish the relationship between the two tables. Unlike a primary key, a foreign key need not be unique• A foreign key must either match a primary key or else be null

– Secondary key: is a field or combination of fields that can be used to access or retrieve records. Secondary key values are not unique. For example, if you need to access records for only those customers in a specific ZIP code, you would use the ZIP code field as a secondary key. Secondary keys also can be used to sort or display records in a certain order.

Page 25: Systems Design Part 3

Avicenna System Analysis and Design System Design 25

Data Design Terminology

• Entity Integrity– Entity integrity constraints are rules for primary

keys:• The primary key cannot have a null value• If the primary key is a composite key, none of the fields

in the key can contain a null value

Page 26: Systems Design Part 3

Avicenna System Analysis and Design System Design 26

Data Design Terminology• Referential Integrity– Validity checks can help avoid data input errors– One type of validity check, called referential integrity, is a set

of rules that avoids data inconsistency and quality problems– In a relational database, referential integrity means that a

foreign key value cannot be entered in one table unless it matches an existing primary key in another table

– Referential integrity also can prevent the deletion of a record has a primary key that matches foreign keys in another table

Page 27: Systems Design Part 3

27

Data Design Terminology

Combination primary key

Primary keys

Foreign key

Secondary key

Candidate keys

Page 28: Systems Design Part 3

Relational ModelsBasic rules of converting an ERD into Relational Model

• Each entity will be represented as tables.• Attributes of each entity will be represented as

fields/tuples.• In 1:1 relationships, the primary key of one entity should

be added as foreign key of the other entity.• In 1:M relationships, the primary key of the 1 side should

be added as a foreign key of the M side.• In M:N relationships, the primary keys of both sides will be

combined as composite keys in the third table to be created for the associative entity.

Page 29: Systems Design Part 3

End