Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
M1 M2InfoMan
S1 part1 InfoMan
| Question | Answer |
|---|---|
| organized collection of logically related data | Database |
| stored representations of meaningful objects and events | Data |
| data processed to increase knowledge in the person using the data | Information |
| data that describes the properties and context of user data | Metadata |
| numbers, text, dates | Structured Data |
| images, video, documents | Unstructured Data |
| ___ Helps Users Understand Data | Context |
| ___ ___ turn data into useful information that managers can use for decision making and interpretation | Graphical displays |
| All programs maintain metadata for each file they use | Program-Data Dependence(Disadvantages of File Processing) |
| Different systems/programs have separate copies of the same data | Duplication of Data(Disadvantages of File Processing) |
| No centralized control of data | Limited Data Sharing(Disadvantages of File Processing) |
| Programmers must design their own file formats | Lengthy Development Times(Disadvantages of File Processing) |
| 80% of information systems budget | Excessive Program Maintenance(Disadvantages of File Processing) |
| • Central repository of shared data • Data is managed by a controlling agent • Stored in a standardized, convenient form Requires a Database Management System (DBMS) | SOLUTION: The DATABASE Approach |
| A software system that is used to create, maintain, and provide controlled access to user databases | Database Management System |
| Program-data independence is an advantage of the database approach.(T/F) | True |
| Planned data redundancy is considered an advantage of the database approach.(T/F) | True |
| Improved data consistency is an advantage of the database approach.(T/F) | True |
| Improved data sharing is an advantage of the database approach.(T/F) | True |
| Increased application development productivity is an advantage of the database approach. (T/F) | True |
| Enforcement of standards is an advantage of the database approach.(T/F) | True |
| Improved data quality is an advantage of the database approach.(T/F) | True |
| Improved data accessibility and responsiveness is an advantage of the database approach.(T/F) | True |
| Reduced program maintenance is an advantage of the database approach.(T/F) | True |
| Improved decision support is an advantage of the database approach.(T/F) | True |
| New, specialized personnel is a Cost and Risk of Database Approach | Yes |
| Installation and management cost and complexity is a Cost and Risk of Database Approach | Yes |
| Conversion costs is a Cost and Risk of Database Approach | Yes |
| Need for explicit backup and recovery is a Cost and Risk of Database Approach | Yes |
| Organizational conflict is a Cost and Risk of Database Approach | Yes |
| – Noun form describing a person, place, object, event, or concept – Composed of attributes | Entities(Elements of Database Approach) |
| Graphical system capturing nature and relationship of data – Enterprise ___ ___–high-level entities and relationships for the organization – Project ___ ___–more detailed view, matching data structure in database or data warehouse | Data Models(Elements of Database Approach) |
| – Between entities – Usually one-to-many (1:M) or many-to-many (M:N) | Relationships(Elements of Database Approach) |
| – Database technology involving tables (relations) representing entities and primary/foreign keys representing relationships | Relational Databases(Elements of Database Approach) |
| computer-aided software engineering | CASE Tools(Components of Database Environment) |
| centralized storehouse of metadata | Repository(Components of Database Environment) |
| software for managing the database | Database Management System (DBMS)(Components of Database Environment) |
| storehouse of the data | Database(Components of Database Environment) |
| software using the data | Application Programs(Components of Database Environment) |
| text and graphical displays to users | User Interface(Components of Database Environment) |
| personnel responsible for maintaining the database | Data/Database Administrators(Components of Database Environment) |
| personnel responsible for designing databases and software | System Developers(Components of Database Environment) |
| people who use the applications and databases | End Users(Components of Database Environment) |
| software using the data | Application Programs(Components of Database Environment) |
| text and graphical displays to users | User Interface(Components of Database Environment) |
| personnel responsible for maintaining the database | Data/Database Administrators(Components of Database Environment) |
| personnel responsible for designing databases and software | System Developers(Components of Database Environment) |
| people who use the applications and databases | End Users(Components of Database Environment) |
| Detailed, well-planned development process –Time-consuming, but comprehensive –Long development cycle | System Development Life Cycle(SDLC) |
| –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 | Prototyping |
| Detailed, well-planned development process –Time-consuming, but comprehensive –Long development cycle | System Development Life Cycle(SDLC) |
| Purpose–preliminary understanding Deliverable–request for study Database activityenterprise modeling and early conceptual data modeling | Planning |
| –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 | Prototyping |
| Purpose–thorough requirements analysis and structuring Deliverable–functional system specifications Database activity–thorough and integrated conceptual data modeling | Analysis |
| Purpose–information requirements elicitation and structure Deliverable–detailed design specifications Database activitylogical database design (transactions, forms, displays, views, data integrity and security) | Logical Design |
| Purpose–preliminary understanding Deliverable–request for study Database activityenterprise modeling and early conceptual data modeling | Planning |
| Database activityphysical database design (define database to DBMS, physical data organization, database processing programs) | Physical Design |
| Purpose–thorough requirements analysis and structuring Deliverable–functional system specifications Database activity–thorough and integrated conceptual data modeling | Analysis |
| Purpose–information requirements elicitation and structure Deliverable–detailed design specifications Database activitylogical database design (transactions, forms, displays, views, data integrity and security) | Logical Design |
| Purpose–develop technology and organizational specifications Deliverable–program/data structures, technology purchases, organization redesigns | Physical Design |
| Database activityphysical database design (define database to DBMS, physical data organization, database processing programs) | Physical Design |
| Purpose–programming, testing, training, installation, documenting Deliverable–operational programs, documentation, training materials Database activitydatabase implementation, including coded programs, documentation, installation and conversion | Implementation |
| Purpose–monitor, repair, enhance Deliverable–periodic audits Database activitydatabase maintenance, performance analysis and tuning, error corrections | Maintenance |
| READ DATABASE METHODOLOGY | |
| • User Views • Subsets of Conceptual Schema • Can be determined from business-function/data entity matrices • DBA determines schema for different users | External Schema |
| • E-R models | Conceptual Schema |
| • Logical structures • Physical structures | Internal Schema |
| Project–a planned undertaking of related activities to reach an objective that has a beginning and an end(Managing Projects) | JUST READ |
| Initiated and planned in planning stage of SDLC(Managing Projects) | JUST READ |
| Executed during analysis, design, and implementation(Managing Projects) | JUST READ |
| Closed at the end of implementation(Managing Projects) | JUST READ |
| READ THE PEOPLE INVOLVED | |
| JUST READ THE TIMELINE SINCE IT'S FULL OF IMAGES | |
| Personal databases • Multitier client/server databases • Enterprise applications • Enterprise resource planning (ERP) systems • Data warehousing implementations | Range of Database Applications |
| word or phrase with specific meaning | Term |
| association between two or more terms | Fact |
| • Related to business, not technical, characteristics • Meaningful and self-documenting • Unique • Readable • Composed of words from an approved list • Repeatable • Written in standard syntax | Good Data Name |
| person, place, object, event, concept (often corresponds to a row in a table) | Entity instance |
| collection of entities (often corresponds to a table) | Entity Type |
| link between entities (corresponds to primary k foreign key equivalencies in related tables) | Relationship instance |
| category of relationship…link between entity types | Relationship type |
| Properties or characteristics of an entity or relationship type (often corresponds to a field in a table) | Attributes |
| • Entities are represented by softboxes • Entity names go in the softboxes • Entity names are always singular and written in capital letters | Barker Notation |
| 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: “#” | Barker Notation |
| -Statements that define or constrain some aspect of the business -Derived from policies, procedures, events, functions -Assert business structure -Control/influence business behavior -Expressed in terms familiar to end users -Automated DBMS | Business Rule |
| what, not how | Declarative |
| clear, agreed-upon meaning | Precise |
| one statement | Atomic |
| internally and externally | Consistent |
| structured, natural language | Expressible |
| non-redundant | Distinct |
| understood by business people | Business-oriented |
| a person, a place, an object, an event, or a concept in the user environment about which the organization wishes to maintain data | Entity |
| a collection of entities that share common properties or characteristics | Entity type |
| A single occurrence of an entity type | Entity instance |
| property or characteristic of an entity or relationship type | Attribute |
| • exists independently of other types of entities • has its own unique identifier • identifier underlined with single line | Strong 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 | Weak entity |
| • links strong entities to weak entities | Identifying relationship |
| • 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 sho... | Naming Attributes |
| must have a value for every entity (or relationship) instance with which it is associated | Required |
| may not have a value for every entity (or relationship) instance with which it is associated | Optional |
| An attribute that has meaningful component parts (attributes) | Composite attribute |
| may take on more than one value for a given entity (or relationship) instance | Multivalued |
| values can be calculated from related attribute values (not physically stored in the database) | Derived |
| an attribute (or combination of attributes) that uniquely identifies individual instances of an entity type | Identifier (Key) |
| • 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 | Criteria for identifiers |
| • The relationship type is modeled as lines between entity types…the instance is between specific entity instances | Relationship Types vs. Relationship Instances |
| • These describe features pertaining to the association between the entities in the relationship | Relationships can have attributes |
| • Two entities can have more than one type of relationship between them (multiple relationships) • Associative Entity–combination of relationship and entity | Modeling Relationships |
| Degree of a relationship is the number of entity types that participate in it • Unary Relationship • Binary Relationship • Ternary Relationship | |
| Each entity in the relationship will have exactly one related entity | One-to-One |
| 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 | One-to-Many |
| Entities on both sides of the relationship can have many related entities on the other side | Many-to-Many |
| the number of instances of one entity that can or must be associated with each instance of another entity | Cardinality Constraints |
| • If zero, then optional • If one or more, then mandatory | Minimum Cardinality |
| The maximum number | Maximum Cardinality |
| READ ABOUT ASSOCIATIVE ENTITY |
Created by:
user-1776272