Information Management.docx

Information Management Module 1: Database Environment and Development Process Definitions **Database**: organized collection of logically related data **Data**: stored representations of meaningful objects and events ** Structured**: numbers, text, dates ** Unstructured**: images, video,...

Information Management Module 1: Database Environment and Development Process Definitions **Database**: organized collection of logically related data **Data**: stored representations of meaningful objects and events ** Structured**: numbers, text, dates ** Unstructured**: images, video, documents ** Information**: data processed to increase knowledge in the person using the data **Metadata**: data that describes the properties and context of user data **Data in context** **Summarized data**  Graphical displays turn data into useful information that managers can use for decision making and interpretation Example of Metadata Descriptions of the **properties or characteristics** of the data, including data types, field sizes, allowable values, and data context Disadvantage of File Processing **\>Program-Data Dependence** All programs maintain metadata for each file they use **\>Duplication of Data** Different systems/programs have separate copies of the same data **\>Limited Data Sharing** No centralized control of data **\>Lengthy Development Times** Programmers must design their own file formats **\>Excessive Program Maintenance** 80% of information systems budget  Solution: The Database Approach Central repository of shared data Data is managed by a controlling agent Stored in a standardized, convenient form Requires a Database Management System (DBMS) Database Management System A software system that is used to create, maintain, and provide controlled access to user databases Advantage of The Database Approach 1\. Program-data independence 2\. Planned data redundancy 3\. Improved data consistency 4\. Improved data sharing 5\. Increased application development productivity 6\. Enforcement of standards 7\. Improved data quality 8\. Improved data accessibility and responsiveness 9\. Reduced program maintenance 10.Improved decision support Cost and Risk of the Database Approach 1\. New, specialized personnel 2\. Installation and management cost and complexity 3\. Conversion costs 4\. Need for explicit backup and recovery 5\. Organizational conflict Elements of the Database Approach **Data models** -- Graphical system capturing nature and relationship of data - Enterprise Data Model - high-level entities and relationships for the organization - Project Data Model - more detailed view, matching data structure in database or data warehouse **Entities** - Noun form describing a person, place, object, event, or concept - Composed of attributes **Relationships** - Between entities - Usually one-to-many (1:M) or many-to-many (M:N) **Relational Databases** - Database technology involving tables (relations) representing entities and primary/foreign keys representing relationships **Components of the Database Environment** - System Development Life Cycle - Detailed, well-planned development process - Time-consuming, but comprehensive - Long development cycle - Rapid application development (RAD) - Cursory attempt at conceptual data modeling - Define database during development of initial prototype - Repeat implementation and maintenance activities with new prototype versions Database Schema **External Schema** User Views Subsets of Conceptual Schema Can be determined from business-function/data entity matrices DBA determines schema for different users **Conceptual Schema** E-R models Internal Schema Logical structures Physical structures Three - Schema Architecture  **Managing Projects** Project--a planned undertaking of related activities to reach an objective that has a beginning and an end Initiated and planned in planning stage of SDLC Executed during analysis, design, and implementation Closed at the end of implementation **Managing Projects: People Involved:** Business analysts Systems analysts Database analysts and data modelers Data/Database administrators Project managers Users Programmers Database architects Other technical experts **Evolution of Database Systems** Driven by four main objectives: Need for program-data independence ➔ reduced maintenance Desire to manage more complex data types and structures Ease of data access for less technical personnel Need for more powerful decision support platforms Figure 1-10a Evolution of database technologies  **Database architectures**  **The Range of Database Applications** Personal databases Multitier client/server databases Enterprise applications Enterprise resource planning (ERP) systems Data warehousing implementations  **Multitiered Client / server database architecture** **Computer System for Pine Vally Furniture Company**  **Module 2: Modeling Data in The Organization** **Entity Relationship Diagram** **Data Definitions** **Explanation of a term or fact** Term--word or phrase with specific meaning Fact--association between two or more terms **Guidelines for good data definition** A concise description of essential data meaning Gathered in conjunction with systems requirements Accompanied by diagrams Achieved by consensus, and iteratively refined **A Good Data Name is:** Related to business, not technical, characteristics Meaningful and self-documenting Unique Readable Composed of words from an approved list Repeatable Written in standard syntax **E-R Model Constructs** **Entities:** Entity instance--person, place, object, event, concept (often corresponds to a row in a table) Entity Type--collection of entities (often corresponds to a table) **Relationships:** Relationship instance--link between entities (corresponds to primary key foreign key equivalencies in related tables) Relationship type--category of relationship...link between entity types **Attributes:** Properties or characteristics of an entity or relationship type (often corresponds to a field in a table) **Sample E-R Diagram** **Basic E-R Notation**  Data Modeler Drawing Conventions(Barker Notation) Entities are represented by softboxes Entity names go in the softboxes Entity names are always singular and written in capital letters Attributes are listed under entity names Mandatory attributes are marked with an asterisk: "\*" Optional attributes are marked with a circle: "o" Unique identifiers are marked with a hash sign: "\#" **Business Rules** Are statements that define or constrain some aspect of the business Are derived from policies, procedures, events, functions Assert business structure Control/influence business behavior Are expressed in terms familiar to end users Are automated through DBMS software **A Good Business Rule** Declarative--what, not how Precise--clear, agreed-upon meaning Atomic--one statement Consistent--internally and externally Expressible--structured, natural language Distinct--non-redundant Business-oriented--understood by business people **Entities And Attributes** Entity -- a person, a place, an object, an event, or a concept in the user environment about which the organization wishes to maintain data Entity type -- a collection of entities that share common properties or characteristics Entity instance -- A single occurrence of an entity type Attribute--property or characteristic of an entity or relationship type  **Entities** Entity -- a person, a place, an object, an event, or a concept in the user environment about which the organization wishes to maintain data Entity type -- a collection of entities that share common properties or characteristics Entity instance -- A single occurrence of an entity type **Entity Type and Entity Instance** **Example of Inappropriate Entities**  Strong vs. Weak Entities, and Identifying Relationships **Strong entity** exists independently of other types of entities has its own unique identifier identifier underlined with single line **Weak entity** dependent on a strong entity (identifying owner)...cannot exist on its own does not have a unique identifier (only a partial identifier) entity box and partial identifier have double lines **Identifying relationship** links strong entities to weak entities **Example of a weak Identity and its Identifying relationship** **Attributes** Attribute--property or characteristic of an entity or relationship type **Naming Attributes** Name should be a singular noun or noun phrase Name should be unique Name should follow a standard format e.g. \[Entity type name { \[ Qualifier \] } \] Class Similar attributes of different entity types should use the same qualifiers and classes **Defining Attributes** State what the attribute is and possibly why it is important Make it clear what is and is not included in the attribute's value Include aliases in documentation State source of values Specify required vs. optional State min and max number of occurrences allowed Indicate relationships with other attributes **Classification of Attributes** Required versus Optional Attributes Simple versus Composite Attribute Single-Valued versus Multivalued Attribute Stored versus Derived Attributes Identifier Attributes **Required vs. Optional Attributes**  **Simples vs. Composite Attributes** Composite attribute -- An attribute that has meaningful component parts (attributes) Multi-valued and Derived Attributes **Multivalued** -- may take on more than one value for a given entity (or relationship) instance **Derived** -- values can be calculated from related attribute values (not physically stored in the database) Entity with multivalued attribute (Skill) and derived attribute (Years Employed)  **Identifiers (Keys)** Identifier (Key)--an attribute (or combination of attributes) that uniquely identifies individual instances of an entity type Simple versus Composite Identifier Candidate Identifier--an attribute that could be a key...satisfies the requirements for being an identifier **Criteria For Identifiers** Choose Identifiers that Will not change in value Will not be null Avoid intelligent identifiers (e.g., containing locations or people that might change) Substitute new, simple keys for long, composite keys Simple and Composite **Identifier** Attributes Modeling Relationships **Relationship Types vs. Relationship Instances** - The relationship type is modeled as lines between entity types...the instance is between specific entity instances **Relationships can have attributes** - These describe features pertaining to the association between the entities in the relationship **Two entities can have more than one type of relationship between them (multiple relationships)** **Associative Entity--combination of relationship and entity** **Relationship Types and Instances**  Degree of Relationship ** Degree of a relationship is the number of entity types that participate in it** Unary Relationship Binary Relationship Ternary Relationship a. Unary Relationships  b. Binary relationships c. Ternary Relationship  Cardinality of Relationship **One-to-One** Each entity in the relationship will have exactly one related entity **One-to-Many** An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity **Many-to-Many** Entities on both sides of the relationship can have many related entities on the other side Cardinality Constraints Cardinality Constraints---the number of instances of one entity that can or must be associated with each instance of another entity **Minimum Cardinality** - If zero, then optional - If one or more, then mandatory **Maximum Cardinality** - The maximum number Examples of Cardinality Constraints: a. Mandatory Cardinalities b. One optional, one mandatory c. Optional cardinality Example of multiple Relationship a. Employees and Departments  b. Professors and courses (fixed lower limit constraint) Multivalued attributes can be represented as relationships  Associative Entities **An entity--has attributes A relationship--links entities together When should a relationship with attributes instead be an associative entity?** All relationships for the associative entity should be many The associative entity could have meant independent of the other entities The associative entity preferably has a unique identifier, and should also have other attributes The associative entity may participate in other relationships other than the entities of the associated relationship Ternary relationships should be converted to associative entities **An associative entity (CERTIFICATION)** Associative entity is like a relationship with an attribute, but it is also considered to be an entity in its own right. Note that the many-to-many cardinality between entities in Figure 2-11a has been replaced by two one-to-many relationships with the associative entity. **Cardinality constraints in a ternary relationship**  ERD example Business Rules: A library system contains books, authors and patrons, with attributes book number, author number and patron number, respectively. Books are further described by title and page count Authors by author name, and Patrons by patron name. Books should have at least one author or can have more. An author can author a book or many books Patrons borrow books but at any point in time, may not have anything checked out. When they do have a book checked out, there is a due date associated with it. **Cardinality Constraints in a ternary Relationship**  Figure 2-22 Data model for Pine Valley Furniture Company in Microsoft Visio notation Different modeling software tools may have different notation for the same constructs. Summary in this lesson, you should have learned the following: Importance of data modeling Unary, binary, and ternary relationships Model different types of attributes, entities, relationships, and cardinalities Draw E-R diagrams for common business situations Convert many-to-many relationships to associative entities