IM201 CHAPTER 2 Enterprise Data Modeling The first step in database development in which the scope/range and general

contents of organizational databases are specified. This step typically occurs during information systems planning for an organization. Its purpose is to create an overall picture or explanation of organizational data, not the design for a particular database. review current systems, analyze the nature of the business areas to be supported, describe the data needed at a very high level of abstraction, and plan one or more database development projects Information Systems Architecture A conceptual blueprint or plan that expresses the desired future structure for the information systems in an organization. Consists of six key components: Data can be presented at a general level Processes manipulate data (can be represented by data flow diagrams, object-models with methods, or other notations) Networks - transport data around the organization and between the organization and its key business partners (which can be shown by a schematic of the network links and topology) People - perform processes and are the sources and receivers of data and information Events and points in time when processes are performed (can be shown by state-transition diagrams and other means) Reasons - for events and rules that govern the processing of data (often shown in textual form; but some diagramming tools, such as decision tables, exist for rules) INFORMATION ENGINEERING A formal, top-down methodology that uses a data orientation to create and maintain information systems. emphasizes the importance of understanding relevant data when creating and maintaining information systems. data are modeled in the context of the enterprise, not by detailed consideration of data usage or technology. Top-down planning: A generic information systems planning methodology that attempts to gain a broad understanding of the information system needs of the entire organization.

offers the advantages of a broad perspective, a way to look at integration of individual system components, an understanding of the relationship of information systems to business objectives, and an understanding of the impact of information systems across the whole organization.

Information engineering includes four steps: planning, analysis, design, and implementation. INFORMATION SYSTEMS PLANNING goal is to align information technology with the business strategies of the organization. Such an alignment is important in order to achieve the maximum benefits from investments in information systems and technologies Planning phase: 1. Identifying strategic planning factors - The strategic planning factors are organization goals, critical success factors, and problem areas. - The purpose of identifying these factors is to develop the planning context and to link information systems plans to the strategic business plans. 2. Identifying corporate planning objects - Define the business scope. - The scope limits subsequent systems analysis and where information system changes can occur. KEY PLANNING OBJECTS Organizational units - various departments of the organization. Organizational locations -places where business operations occur. Business functions - Related groups of business processes that support the mission of the organization. A function may be assigned to more than one organizational unit Entity types - Major categories of data about the people, places, and things managed by the organization. Information systems - The application software and supporting procedures for handling sets of data. 3. Developing an enterprise model Functional decomposition - An iterative process of breaking down the description of a system into finer and finer detail in which one function is described in greater detail by a set of other, supporting functions. It is a classical process employed in systems analysis to simplify problems, isolate attention, and identify components. Enterprise data model - often described using entity-relationship diagramming, Besides such a graphical depiction of the entity types, a

thorough enterprise data model would also include business-oriented descriptions of each entity type and a compendium of various statements about how the business operates, called business rules, which govern the validity of data. It shows not only the entity types, but also the relationship between entities. Planning matrixes format for showing the interrelationships between planning objects. It serves an important function because they provide an explicit approach for describing business requirements without requiring that the database be explicitly modeled. TYPES OF PLANNING MATRIXES: o Location-to-function - Indicates which business functions are being performed at which business locations o Unit-to-function - Identifies which business functions are performed by or are the responsibility of which business units o Information system-la-data entity - Explains how each information system interacts with each data entity (e.g., whether each system creates, retrieves, updates, or deletes data in each entity) o Supporting function-to-data entity - Identifies which data are captured, used, updated, or deleted within each function o Information system-to-objective - Shows which information systems support each business objective

Database Development Process Information systems planning, which is based on information engineering, is one source of database development projects. Such projects often develop new databases to meet strategic organizational needs, such as improved customer support, better production and inventory management, or more accurate sales forecasting. Many database development projects arise, however, in a more bottom-up fashion. Approach: Systems Development Life Cycle (SDLC) A traditional process a complete set of steps that a team of information systems professionals, including database designers and programmers, follow in an organization to specify, develop, maintain, and replace information systems. Time consuming, but comprehensive Long development cycle Planning Purpose: To develop a preliminary understanding of a business situation and how information systems might help solve a problem or make an opportunity possible

Deliverable: A written request to study the possible changes to an existing system or the development of a new system that address an information systems solution to the business problems or opportunities Database activity enterprise modeling and early conceptual data modeling Analysis Purpose: To analyze the business situation thoroughly to determine requirements, to structure those requirements, and to select among competing system features ; thorough requirements analysis and structuring Deliverables: The functional specifications for a system that meets user requirements and is feasible to develop and implement Database activity thorough and integrated conceptual data modeling Design (Logical or Physical) Purpose: (L) To elicit and structure all information requirements; (P) to develop all technology and organizational specifications Deliverables: (L) Detailed functional specifications of all data, forms, reports, displays, and processing rules; (P) program and database structures, technology purchases, physical site plans, and organizational redesigns Database activity (L) logical database design (transactions, forms, displays, views, data integrity and security; (P) physical database design (define database to DBMS, physical data organization, database processing programs) Implementation Purpose: To write programs, build data files, test and install the new system, train users, and finalize documentation; programming, testing, training, installation, documenting Deliverables: Programs that work accurately and to specifications, documentation, and training materials; Database activity database implementation including coded programs, documentation, installation and conversion Maintenance Purpose: To monitor the operation and usefulness of a system, and to repair and enhance the system Deliverables: Periodic audits of the system to demonstrate whether the system is accurate and still meet needs Database activity database maintenance, performance analysis and tuning, error corrections

Prototyping Rapid Application Development an iterative process of systems development in which requirements are converted to a working system that is continually revised through close work between analysts and users. Define database during development of initial prototype Repeat implementation and maintenance activities with new prototype versions

documentation. A repository helps systems and database analysts achieve a seamless integration of data from several CASE tools. Managing Projects Project is a planned undertaking of related activities to reach an objective that has a beginning and an end. A project begins with the first steps of the Project Initiation and Planning phase and ends with the last steps of the Implementation phase. Project leader responsible for creating detailed project plans as well as staffing and supervising the project team. A good project leader will possess skills in leadership, management, customer relations and communications, technical problem solving, conflict management, team building, and risk and change management. People involved: Business analysts- Work with both management and users to analyze the business situation and develop detailed system and program specifications for projects Systems analysts- May perform business analyst activities but also specify computer systems requirements and typically have a stronger programming background than business analysts do Database analysts and data modelers- Concentrate on determining the requirements and design for the database component of the information system Users- Provide assessment of their information needs and monitor that the developed system meets their needs Programmers- Design and write computer programs that have commands to maintain and access data in the database embedded in them Database architects- Establish standards for data in business units, striving to attain optimum data location, currency, and quality Data administrators- Have responsibility for existing and future databases and ensure consistency and integrity across databases, and as experts on database technology, provide consulting and training to other project team members Project managers- Oversee assigned projects, including team composition, analysis, design, implementation and support of projects Other technical experts- For example, networking, operating systems, testing, data warehousing and documentation Project closedown- occurs when the project is naturally or unnaturally terminated. Unnatural termination- occurs when the system no longer appears to have business value, when the performance of the system or the development team is unacceptable, or when the project runs out of time, funding. or support. Review points: Validate that the project is progressing in a satisfactory way Step back from the details of daily activities and verilY that all the parts of the project are coming together

Packaged Data Models Model components that can be purchased at comparatively low cost and, after suitable customization, assembled into full-scale data models. Advantages: Reduced development time; Higher model quality and reliability TYPES Universal Data Models applicable to nearly any business or organization Numerous core subject areas are common to many (or even most) organizations, such as customers, products, accounts, documents, and projects. Although they differ in detail, the underlying data structures are often quite similar for these subjects. Industry-Specific Data Models These are generic data models that are designed to be used by organizations within specific industries. Computer-aided software engineering (CASE) Software tools that provide automated support for some portion of the systems development process. Three database features Data modeling drawing entity-relationship diagrams Code generation SQL code for table creation; this code contains the database definition commands to be given to a database management system. Repositories - a knowledge base of information about the facts that an enterprise must be able to access and the processes it must perform to be successful. a repository is a database itself which contains information needed to generate all the diagrams, form and report definitions, and other system

 Gain renewed commitment from all parties to the project (especially important for projects that last more than a few months) Incremental commitment is a strategy in systems development projects in which the project is reviewed after each phase and continuation of the project is rejustified in each of these reviews. Three- Schema Architecture for Database Development 1. External Schema is the view (or views) of managers and other employees who are the database users. Can be represented as a combination of the enterprise data model (a topdown view) and a collection of detailed (or bottom-up) user views. Can be determined from business-function/data entity matrices Ex. GUI of SW applications, forms and reports 2. Conceptual Schema combines the different external views into a single, coherent definition of the enterprise's data. represents the view of the data architect or data administrator. Also known as data model Ex. E-R models and object modeling notations 3. Internal Schema consists of two separate schemas: a logical schema and a physical schema. Logical Schema - The logical schema is the representation of data for a type of data management technology - process of transforming the conceptual data model into a logical data model. - Considers consistency & compatibility with the preferred type of DB technology - Goal: creating stable database structures based on the results of the conceptual model. Physical Schema - The physical schema describes how data are to be represented and stored in secondary storage using a particular DBMS - Describes the organization of physical records, the choice of file organizations, the use of indexes, etc. Three-Tiered Database Location Architecture Tiers of Computers refers to the setup wherein data for a given information system reside in multiple locations 1. Client Tier - A desktop or laptop computer, which concentrates on managing the user-system interface and localized data-also called the presentation tier. Web scripting tasks may be executed on this tier.

2.

Application/Web server tier - Processes HTTP protocol, 'Scripting tasks, performs calculations, and provides access to data-also called the process services tier. 3. Enterprise server (minicomputer or mainframe) tier - Performs sophisticated calculations and manages the merging of data from multiple sources across the organization-also called the data services tier. Client-server architecture - A LAN based environment in which database software on a server (called a database server or database engine) performs database commands sent to it from client workstations, and application programs on each client concentrate on user interface functions. CHAPTER 3 Business Rules Statements that define or constrain some aspect of the business Intend to assert business structure or control/influence business behavior Characteristics of a Good Business Rule Declarative - A business rule is a statement of policy, not how policy is enforced or conducted; the rule does not describe a process or implementation, but rather describes what a process validates. (what, not how) Precise - With the related organization, the rule must have only one interpretation among all interested people, and its meaning must be clear (clear, agreed-upon meaning) Atomic - A business rule marks one statement, not several; no part of the rule can stand on its own as a rule (that is, the rule is indivisible, yet sufficient)

Consistent - A business rule must be internally consistent (that is, not contain conflicting statements) and must be consistent with (and not contradict) other rules; internally and externally Expressible - A business rule must be able to be stated in natural language, but it will be stated in a structured natural language so that there is no misinterpretation Distinct - Business rules are not redundant, but a business rule may refer to other rules (especially refer to definitions) Business-oriented - A business rule is stated in terms business people can understand, and since it is a statement of business policy, only business people can modify or invalidate a rule; thus, a business rule is owned by the business

o o

Concise description of essential data meaning Achieved by consensus, and iteratively refined

E-R MODEL is a detailed, logical representation of the data for an organization or for a business area.
Entity-relationship diagram (E..R diagram or ERD): A graphical representation of an entity-

relationship model.

Entity - is a person, place, object, event, or concept in the user environment about which the organization wishes to maintain data. Thus, an entity has a noun name. Entity type: A collection of entities that share common properties or characteristics. Entity instance: A single occurrence of an entity type. What Should an Entity Be? SHOULD BE: o An object that will have many instances in the database o An object that will be composed of multiple attributes o An object that we are trying to model SHOULD NOT BE: o A user of the database system o An output of the database system (e.g., a report) Strong entity type: An entity that exists independently of other entity types. Example: STUDENT, EMPLOYEE, AUTOMOBILE, COURSE Weak entity type: An entity type that whose existence depends on some other entity type. Identifying owner (owner): The entity type on which the weak entity type depends Identifying relationship: The relationship between a weak entity type and its owner Attribute: A property or characteristic of an entity or relationship type that is of interest to the organization. Classifications of attributes: o Required versus Optional Attributes o Simple versus Composite Attribute o Single-Valued versus Multivalued Attribute o Stored versus Derived Attributes o Identifier Attributes Required attribute: An attribute that must have a value for every entity (or relationship) instance. Optional attribute: An attribute that may not have a value for every entity (or relationship) instance. Composite attribute: An attribute that has meaningful component parts.

A Good Data Name Is: Relate to Business, not Technical (Hardware or Software) Characteristics; so, Customer is a good name, but File10, Bit7, and PayrollReportSortKey are not good names. Be Meaningful almost to the point of being self-documenting (i.e., the definition will refine and explain the name without having to state the essence of the object's meaning); you should avoid using generic words such as "has," "is," "person," it Be Unique from the name used for every other distinct data object; words should be included in a data name if they distinguish the data object from other similar data objects (e.g., HomeAddress versus CampusAddress). Be Readable, so that the name is structured as the concept would most naturally be said (e.g., GradePointAverage is a good name, whereas AverageGradeRelativeToA, although possibly accurate, is an awkward name). Be Composed of Words Taken from an Approved List; each organization often chooses a vocabulary from which significant words in data names must be chosen (e.g., maximum is preferred, never upper limit, ceiling, or highest); alternative, or alias names, also can be used as can approved abbreviations (e,g" CUST for Customer), and you may be encouraged to use tq.e abbreviations so that data names are short enough to meet maximum length limits of database technology. Be Repeatable, meaning that different people or the same person at different times should develop exactly or almost the same name; this often means that there is a standard hierarchy or pattern for names (e,g., the birth date of a student would be StudentBirthDate and the birth date of an employee would be (EmployeeBirthDate). Data Definitions an explanation of a term or a fact o Termword or phrase with specific meaning o Factassociation between two or more terms Guidelines for good data definition o Gathered in conjunction with systems requirements o Accompanied by diagrams

Simple (or atomic) attribute: An attribute that cannot be broken down into smaller components that is meaningful to the organization. Multivalued attribute: An attribute that may take on more than one value for a given entity (or relationship) instance. Derived attribute: An attriibute whose values can be calculated from related attribute values. Identifier: An attribute (or combination of attributes) that uniquely distinguishes individual instances of an entity type. Characteristics of Identifiers o Will not change in value o Will not be null o No intelligent identifiers (e.g., containing locations or people that might change) o Substitute new, simple keys for long, composite keys

Many-to-Many Entities on both sides of the relationship can have many related entities on the other side

o o

Cardinality Constraints Cardinality Constraintsthe 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

Relationship type: A meaningful association between (or among) entity types. Relationship instance: An association between (or among) entity instances where each relationship instance includes exactly one entity from each participating entity type. o Relationships can have attributes o These describe features pertaining to the association between the entities in the relationship o Two entities can have more than one type of relationship between them (multiple relationships) Associative entity: An 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. Degree of Relationships o Degree of a relationship is the number of entity types that participate in it o Unary Relationship o Binary Relationship o Ternary Relationship Cardinality of Relationships o One-to-One Each entity in the relationship will have exactly one related entity o 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

Strong vs. Weak Entities, and Identifying Relationships Strong entities o exist independently of other types of entities o has its own unique identifier o identifier underlined with single line Weak entity o dependent on a strong entity (identifying owner)cannot exist on its own o does not have a unique identifier (only a partial identifier) o partial identifier underlined with double line o entity box has double line Identifying relationship o links strong entities to weak entities Associative Entities An entityhas attributes; A relationshiplinks entities together When should a relationship with attributes instead be an associative entity? o All relationships for the associative entity should be many o The associative entity could have meaning independent of the other entities o The associative entity preferably has a unique identifier, and should also have other attributes o The associative entity may participate in other relationships other than the entities of the associated relationship o Ternary relationships should be converted to associative entities