bis03 data modelling - i

Download BIS03 Data Modelling - I

If you can't read please download the document

Upload: prithwis-mukerjee

Post on 16-Apr-2017

4.496 views

Category:

Education


0 download

TRANSCRIPT

Kollaborative Klassroom Template

Business Information Systems
Data Modeling - I

Prithwis Mukerjee, Ph.D.

What is a Data Model?

student idstudent last namestudent first namestudent dormitory student majorSTUDENTcourse idcourse titlecourse number of creditscourse location course instructor nameCOURSEattends/is taught to

DATA MODELThe specification of data structures and business rules to represent business requirements.

Purpose of Data Modeling

Data Modeling is the process used to:Analyze the dataIdentify the relationshipsCreate the data modelWe use it to visualize informational needs in the form of an Entity Relationship Diagram (ERD)

Business models often coexist with Data Models to enable software development.Other types of modeling:Business Process ModelFunctional ModelObject Model

DATA MODELING A structured approach used to identify major components of an information systems specifications.Data models are the communications devices used for the representation of data, generally depicting the entities or things of interest to an organization and the relationships between those entities. Data models are an important part of the systems development process; they improve communications with users, and provide a sound logical basis for data base design. Data modeling is the process of creating these communications devices. It is a method of visualizing informational needs and typically takes the form of an ERD (Entity Relationship Diagram). Data modeling is the process used to analyze the data, identify the relationships among these data objects, and create the data model.

The Data Modeling Process

Modeling ToolsConceptual Data ModelsLogical Data ModelsPhysical Data Models

Modelling ToolsERwin (Entity Relationship Windows)Sterling Software COOLSystem ArchitectPowerDesignerDBArtisanVISIO

CDM

A Conceptual Data Model is a structured business view of the data required to support current business processes, business events, and related performance measures.It is a single integrated data structure which reflects the structure of the business functions rather than the processing flow or the physical arrangement of data. CharacteristicsRepresents overall logical structure of dataIndependent of software or data storage structureOften contains objects not implemented in physical databasesRepresents data needed to run an enterprise or a business activity

The Conceptual Data Model is a structured business view of the data required to support current business processes, business events, and related performance measurements. This is a single integrated data structure which reflects the structure of the business functions rather than processing flow or physical arrangement of data. It represents the overall logical structure of data required to support the business requirements independent of any software or data storage structure. A conceptual model often contains data objects not yet implemented in physical databases. It is a formal representation of the data needed to run an enterprise or a business activity.

CDM

The conceptual model can then be used to create the logical level, which maps to the designer view in the Zachman framework. The logical model would still be without reference to any specific DBMS, however it would include references to characteristics of databases that are generic in nature (i.e. indices, integrity constraints). It also adds more key and non-key attributes.

A Conceptual Data Model represents the entities, which the owners feel are important for doing business. It gives a formal representation of the data needed to run an enterprise or a business activity. The conceptual data model is the owners view of the business, and will communicate the framework of the organization to the designers. Conceptual Data Models should be reviewed with business and technical users to ensure the following:to enforce common names, data types and size for the same data elements residing in the operational data store and the data warehouse to enforce common definitions of terms across environments and different business unitsto ensure agreement on the scope of the data requirements. The Conceptual Data Model (CDM), in conjunction with the business process model, will be used to design both OLTP (On-line Transactional Processing) systems and OLAP (On-line Analytical Processing) systems.

Logical Data Model

A Logical Data Model builds upon the business requirements and includes a further level of detail that supports both the business and system requirements.

Business rules are incorporated into the LDM and it loses some of the generalities from the Enterprise CDM. CharacteristicsIndependent of specific software and data storage structureIncludes more specific entities and attributesIncludes business rules and relationshipsIncludes foreign keys, alternate keys, and inversion entries

A Logical Data Model builds upon the business requirements and includes a further level of detail that supports both the business and system requirements. Like the Conceptual Data Model, the Logical Data Model is independent of specific software and data storage structures. Indexes and foreign keys are characteristics of databases that are generic in nature and required of the system for processing. Therefore, a Logical Data Model stores those characteristics without adding anything specific to a single DBMS.

Once the development of the logical model is complete, this model can be used to create the physical data model, also known as the builders view. This model will reflect characteristics of databases that are the specific requirements of the data stores and the DBMS.

Entities

Each ENTITY represents a set/collection of like individual objects called instances.Each instance must be uniquely identifiable and distinct from all other instances.Each ENTITY should be named using:Unique entity names in a modelA non-technical, business-like nameA singular noun that describes a singular instance (no collective nouns)

ENTITYA person, place, thing, event, or concept about which the business keeps data.

Defining the Entity

Each entity should be fully defined by the business community to:Identify why the business needs this informationImprove understandingAvoid redundancy

A SERVICE CONTRACT is a PRODUCT representing an AGREEMENT between our COMPANY and the PURCHASER that offers service coverage extending beyond the normal WARRANTY period.Two types of entities:Independent: depends on no other entity for its identification

Dependent: depends on one or more entities for its identification

LINE ITEMORDER

Attributes

attributesemployee first nameemployee last nameemployee addressemployee phone numberEMPLOYEEATTRIBUTEA distinct characteristic of an ENTITY for which data is maintained.

ENTITY Name(above the box)

employee idAttribute Names :Unique attribute names in a model (or entity)A non-technical, business-like nameA singular noun that describes a singular instance (no collective nouns)All lowercase (Erwin standard), with spaces

Attribute Types

Two types of attributes:KeyNon-key

consultant id consultant first nameconsultant last nameconsultant specializationconsultant hourly rateCONSULTANT

Key Attribute(s)(above the line)Non-Key Attribute(s)(below the line)

How do we determine keys?

CANDIDATE KEYAny attribute or group of attributes which serves to uniquely identify each instance of an ENTITY.BOOKBOOKBOOK

author first nameauthor last namebook titlebook editionbook publisherbook year publishedbook isbnbook lc catalog number

author first nameauthor last namebook titlebook editionbook publisherbook year publishedbook isbnbook lc catalog number

author first nameauthor last namebook titlebook editionbook publisherbook year publishedbook isbnbook lc catalog number

Primary Keys

PRIMARY KEY

An ATTRIBUTE or group of attributes that uniquely identifies an instance of the entity.

book isbnauthor first name author last name book title book edition book publisherbook year publishedbook lc catalog number BOOKThe primary key is always placed above the line in an EntityFactors to consider:Should be efficientMust not contain any null partsValues must remain staticShould be a data element in your control

Surrogate Keys

transaction idaccount idcustomer idcash machine idtransaction dateCASH MACHINE TRANSACTIONComposite KeySurrogate Key

account idcustomer idcash machine idtransaction date

CASH MACHINE TRANSACTION

SURROGATE KEYA contrived, non-intelligent, single-attribute key used to replace a long composite key.

Relationships

MOVIEMOVIE COPYis rented asRELATIONSHIPA logical link between two entities that represents a business rule or constraint.

Foreign Keys

FOREIGN KEY (FK)A primary key of a parent entity that is contributed to a child entity across a relationship.containsorder number (FK)
line item sequence numberproduct code
line item quantity
line item number
line item descriptionLINE ITEM

ORDERorder number

order dateorder sales representativeorder customer

Identifying Relationship

MOVIE MASTERmovie master idmovie namemovie starmovie typemovie ratingMOVIE COPYmovie master id (FK)
movie copy numbermovie copy create datemovie copy due datemovie copy condition

is rented as/is created from

The parent Primary Key migrates through the relationship to become part of the Primary Key (IDENTITY) of the childThe child is DEPENDENT upon the parent
for its identification and cannot exist without the parent

Assertion 1: Each MOVIE MASTER 0, 1, or more MOVIE COPYs.Assertion 2: Each MOVIE COPY one and only one MOVIE MASTER.Assertion 3: A MOVIE COPY cannot exist without its MOVIE MASTER.

Many-to-Many Relationship

is ordered from/sends usPARTSUPPLIER

A non-specific relationship in which primary keys do not migrate as foreign keysMust have two verb phrasesEach phrase states the rule from the perspective of:parent to childchild to parent

Assertion 1: Each PART 0, 1, or more SUPPLIERs. Assertion 2: Each SUPPLIER 0, 1, or more PARTs.

Relationship Cardinality

CUSTOMERORDERplaces

DRIVERINSURANCE POLICYcoversP

PASSENGERAIRPLANE SEATis ticketed forZ

TIRECARrequiresNEach parent instance is related to zero, one, or more child instancesEach parent instance is related to one or more child instancesEach parent instance is related to zero or one child instancesEach parent instance is related to exactly N child instances

Recursive Relationships

A non-identifying non-mandatory relationship in which the same entity is both the parent and the child. RECURSIVE RELATIONSHIPA recursive relationship:is always a non-identifying relationshipallows null values for foreign key

Recursive Relationships

The parent entity instances primary key is migrated to the non-key area of the child entity instance.Each migrating primary key attribute must be given a rolename to clarify the attributes foreign key role.

Childs Foreign Key with RolenameParents Primary Keymanages

EMPLOYEEemployee idmanager employee id.employee id (FK)

Referential Integrity : What & Why ?

What is the impact of:Inserting, updating, or deleting a Parent Primary Key value?Inserting, updating, or deleting a Child Foreign Key value?None of these actions should break the relationship from Child to ParentOptions can be specified as to how the DBMS should manage these actions to maintain referential integrity

REFERENTIAL INTEGRITY (RI)
Rules that determine what happens when a Parent or Child instance is inserted, updated or deleted.

Referential Integrity Options

RI OptionWhat It DoesRESTRICTDoes not allow ActionCASCADEDuplicates Action in related tablesSET NULLAllows Action and sets the Child foreign key to NullSET DEFAULTAllows Action and sets the Child foreign key to the Default valueNONENo Restriction placed on Action

Non-identifying Mandatory Relationship

The parent Primary Key migrates as a non-key attribute to the child and does NOT IDENTIFY the childThe child is INDEPENDENT of the parent for its identification, but still cannot exist without a parent (mandatory)

Assertion 1: Each CUSTOMER 0, 1, or more ORDERs.Assertion 2: Each ORDER one and only one CUSTOMER. Assertion 3: An ORDER can be identified without information about a CUSTOMER, but requires a value for the customer id (MUST HAVE A PARENT).

ORDERplaces/is received fromCUSTOMERcustomer id

customer namecustomer address customer phoneorder numbercustomer id (FK)order dateorder statusorder shipdate

Non-identifying Optional Relationship

The parent Primary Key migrates as a non-key attribute to the child and does NOT IDENTIFY the childThe child is INDEPENDENT of the parent for its identificationThe diamond (optionality indicator) indicates that a child may exist without parent information

Assertion 1: Each DEPARTMENT 0, 1, or more EMPLOYEEs.Assertion 2: Each EMPLOYEE OPTIONALLY a DEPARTMENT. Assertion 3: An EMPLOYEE can be identified without information about the DEPARTMENT, and does not have to be associated with a DEPARTMENT (CAN EXIST WITHOUT A PARENT).

EMPLOYEEemployee iddepartment number (FK)employee nameemployee addressemploys/belongs todepartment numberdepartment namedepartment locationDEPARTMENT

Click to edit the title text format

Click to edit the outline text formatSecond Outline LevelThird Outline LevelFourth Outline LevelFifth Outline LevelSixth Outline LevelSeventh Outline LevelEighth Outline LevelNinth Outline Level

Prithwis Mukerjee

Click to edit the outline text formatSecond Outline LevelThird Outline LevelFourth Outline LevelFifth Outline LevelSixth Outline LevelSeventh Outline LevelEighth Outline LevelNinth Outline Level