7.1 The Information system

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "7.1 The Information system"

Transcription

1 Chapter 7. Database Planning, Design and Administration Last few decades have seen proliferation of software applications, many requiring constant maintenance involving: correcting faults, implementing new user requirements, modifying software to run on new or upgraded platforms. As a result, many major software projects were late, over budget, unreliable, difficult to maintain, performed poorly. Copyright 2007 BUPTSSE Guo Wenming Page 1 Chapter 7. Database Planning, Design and Administration In late 1960s, led to software crisis, now refer to as the software depression. There are several major reasons for failure of software projects including: lack of a complete requirements specification; lack of appropriate development methodology; poor decomposition of design into manageable components. As a solution, a structured approach to development was proposed called information systems lifecycle or software development lifecycle. Copyright 2007 BUPTSSE Guo Wenming Page 2 Chapter 7. Database Planning, Design and Administration In this chapter, we present an overview of the database application lifecycle, and describe each stage of the database application in more detail. 7.1 The Information System Lifecycle 7.2 The Database application Lifecycle 7.3 Database Planning 7.4 System Definition 7.5 Requirements Collection and Analysis 7.6 Database Design Copyright 2007 BUPTSSE Guo Wenming Page 3 Chapter 7. Database Planning, Design and Administration 7.7 DBMS Selection 7.8 Application Design 7.9 Prototyping 7.10 Implementation 7.11 Data Conversion and Loading 7.12 Testing 7.13 Operational Maintenance 7.14 Case Tools 7.15 Data Administration and Database Administration Copyright 2007 BUPTSSE Guo Wenming Page 4 Chapter 7. Database Planning, Design and Administration Main components of an information system. Main stages of database application lifecycle. Main phases of database design: conceptual, logical, and physical design. Benefits of CASE tools. How to evaluate and select a DBMS. Distinction between data administration and database administration. Purpose and tasks associated with data administration and database administration. Copyright 2007 BUPTSSE Guo Wenming Page The Information system Information System: The resources that enable collection, management, control, and dissemination of information throughout an organization. The stages in the lifecycle of an I.S. include: planning, requirements collection and analysis, design, prototyping, implementation, testing, conversion, and operational maintenance. The Database is fundamental component of I.S., and its development and usage should be viewed from perspective of the wider requirements of the organization. Copyright 2007 BUPTSSE Guo Wenming Page 6 1

2 7.2 The Database Application Lifecycle The database application lifecycle is inherently associated with the lifecycle of the information system. The stages of the database application lifecycle are shown in Figure in next page. Database planning System definition Requirements collection and analysis Database design DBMS selection (optional) Copyright 2007 BUPTSSE Guo Wenming Page The Database Application Lifecycle Application design Prototyping (optional) Implementation Data conversion and loading Testing Operational maintenance. It is important to recognised that the stages of the database application lifecycle are not strictly sequential, but involve some amount of repetition of previous stages through feedback loops. Copyright 2007 BUPTSSE Guo Wenming Page The Database Application Lifecycle Database Planning System Definition Requirement Collection and Analysis Database Design Conceptual database design DBMS Selection Application Design Logical database design Physical database design Implemtntation Prototyping Data Conversion & Loading Testing Operational Maintenance Copyright 2007 BUPTSSE Guo Wenming Page Database Planning Database Planning: The management activities that allow the stages of the database application to be realized as efficiently and effectively as possible. Database planning must be integrated with the overall IS strategy of the organization. There are three main issues involved in formulating an IS strategy, which are: Identification of enterprise plans and goals with subsequent determination of information systems needs; Evaluation of current information systems to determine existing strengths and weakness; Appraisal of IT opportunities that might yield competitive advantage. Copyright 2007 BUPTSSE Guo Wenming Page Database Planning Mission statement for the database project defines major aims of database application. Those driving database project within the organization (such as Director or Owner) normally define the mission statement. Mission statement helps clarify purpose of the database project and provides clearer path towards the efficient and effective creation of required database application. Once mission statement is defined, mission objectives are defined. Copyright 2007 BUPTSSE Guo Wenming Page Database Planning Each objective should identify a particular task that the database must support. May be accompanied by some additional information that specifies the work to be done, the resources with which to do it, and the money to pay for it all. Database planning should also include development of standards that govern: how data will be collected, how the format should be specified, what necessary documentation will be needed, how design and implementation should proceed. Copyright 2007 BUPTSSE Guo Wenming Page 12 2

3 7.3 Database Planning Example: A mission statement for DreamHome We begin the conducting interviews with the Director and any other appropriate staff, as indicated by the Director. Examples of typical questions we might ask include: What is the purpose of your Company? Why do you feel that you need a database? How do you know that a database will solve your problem? For example, the database developer may start the interview by asking the Director of DreamHome the following questions: Database Developer What is the purpose of your Company? Director We offer a wide range of high quality properties for rent to clients registered at our branches throughout the UK. Our ability to offer quality properties, of course, depends upon the services we provide to property owners. We provide a highly professional service to property owners to ensure that properties are rented out for maximum return. 7.3 Database Planning A mission statement for DreamHome Database Developer Why do you feel that you need a database? Director To be honest we can t cope with our own success. Over the past few years, we ve opened several branches in most of the main cities of the UK, and at each branch we now offer a larger selection of properties to a growing number of clients. However, this success has been accompanied with increasing data management problems, which means that the level of service we provide is falling. Also, there s a lack of cooperation and sharing of information between branches, which is a very worrying development. Database Developer How do you know that a database will solve your problem? Director All I know is that we are drowning in paperwork. We need something that will speed up the way we work by automating a lot of the day-to-day tasks that seem to take forever these days. Also, I want the branches to start working together. Databases will help to achieve this, won t they? Copyright 2007 BUPTSSE Guo Wenming Page 13 Copyright 2007 BUPTSSE Guo Wenming Page Database Planning A mission statement for DreamHome Responses to these types of questions should help to formulate the mission statement. An example mission statement for the DreamHome database application is shown in Figure When we have a clear and unambiguous mission statement that the staff of DreamHome agree with, we move on to define the mission objectives. Please everyone see additional document Dreamhome_case to know about the details. 7.3 Database Planning Copyright 2007 BUPTSSE Guo Wenming Page 15 Copyright 2007 BUPTSSE Guo Wenming Page Database Planning 7.3 Database Planning Copyright 2007 BUPTSSE Guo Wenming Page 17 Copyright 2007 BUPTSSE Guo Wenming Page 18 3

4 7.3 Database Planning 7.3 Database Planning Copyright 2007 BUPTSSE Guo Wenming Page 19 Copyright 2007 BUPTSSE Guo Wenming Page Database Planning 7.3 Database Planning Copyright 2007 BUPTSSE Guo Wenming Page 21 Copyright 2007 BUPTSSE Guo Wenming Page System Definition System Definition: Describes the scope and boundaries of the database application and the major user views. User view defines what is required of a database application from perspective of: a particular job role (such as Manager or Supervisor) or enterprise application area (such as marketing, personnel, or stock control). Database application may have one or more user views. Identifying user views helps ensure that no major users of the database are forgotten when developing requirements for new application. Copyright 2007 BUPTSSE Guo Wenming Page System Definition User views also help in development of complex database application allowing requirements to be broken down into manageable pieces. We present a diagram that represents the scope and boundaries of the DreamHome database application in additional documents. Copyright 2007 BUPTSSE Guo Wenming Page 24 4

5 7.4 System Definition Copyright 2007 BUPTSSE Guo Wenming Page Requirements Collection and Analysis Requirements collection and analysis: The process of collecting and analyzing information about the part of organization to be supported by the database application, and using this information to identify users requirements of new system. Information is gathered for each major user view including: a description of data used or generated; details of how data is to be used/generated; any additional requirements for new database application. Information is analyzed to identify requirements to be included in new database application. Copyright 2007 BUPTSSE Guo Wenming Page Requirements Collection and Analysis Another important activity is deciding how to manage database application with multiple user views. Three main approaches: centralized approach; view integration approach; combination of both approaches. We present the DreamHome Requirements Collection and Analysis in additional documents. Centralized approach Requirements for each user view are merged into a single set of requirements. A global data model is created based on the merged requirements (which represents all user views). 7.5 Requirements Collection and Analysis The centralized approach to managing multi user views 1 to 3. Copyright 2007 BUPTSSE Guo Wenming Page 27 Copyright 2007 BUPTSSE Guo Wenming Page Requirements Collection and Analysis View integration approach Requirements for each user view are used to build a separate data model to represent that user view. The view integration approach involves leaving the requirements for each user view as separate lists of requirements. Data model representing single user view is called a local data model, and is composed of diagrams and documentation describing requirements of a particular user view of database. Local data models are then merged to produce a global data model, which represents all user views for the database. 7.5 Requirements Collection and Analysis The view integration approach to managing multiple user views 1 to 3 Copyright 2007 BUPTSSE Guo Wenming Page 29 Copyright 2007 BUPTSSE Guo Wenming Page 30 5

6 7.5 Requirements Collection and Analysis Director Manager Supervisor Assistant branch X X staff X X X property for rent X X X X owner X X X X client X X X X property viewing X X lease X X X X newspaper X X 7.6 Database Design Database Design: Process of creating a design for a database that will support the enterprise s operations and objectives. Major aims: Represent data and relationships between data required by all major application areas and user groups. Provide data model that supports any transactions required on the data. Specify a minimal design that is appropriately structured to achieve stated performance requirements for the system (such as response times). Copyright 2007 BUPTSSE Guo Wenming Page 31 Copyright 2007 BUPTSSE Guo Wenming Page Database Design In this section we present an overview of the main approaches to database design. We also discuss the purpose and use of data modeling in database design. We then describe the three phases of database design, namely conceptual logical, and physical design approaches to Database Design Data Modeling Phases of Database Design Copyright 2007 BUPTSSE Guo Wenming Page Approaches to Database Design Approaches include: Bottom-up: beginning at fundamental level of attributes, which are grouped into relations. Top-down: starting with the development of data models that contain a few high-level entities and relationships and then identifying lower-level entities, relationships, and the associated attributes. Inside-out: related to bottom-up approach but differing by first identifying a set of major entities and then spreading out to consider other entities, relationships, and attribute with those first identified. Mixed: using both bottom-up and top-down approach. Copyright 2007 BUPTSSE Guo Wenming Page Data Modeling Main purposes of data modeling include: to assist in understanding the meaning (semantics) of the data; to facilitate communication about the information requirements. Building data model requires answering questions about entities, relationships, and attributes. A data model ensures we understand: each user s perspective of the data; nature of the data itself, independent of its physical representations; use of data across user views Data Modeling Criteria for data models Copyright 2007 BUPTSSE Guo Wenming Page 35 Copyright 2007 BUPTSSE Guo Wenming Page 36 6

7 7.6.3 Phases of Database Design Three phases of database design: Conceptual database design Logical database design Physical database design. Conceptual database design: The process of constructing a model of the information used in an enterprise, independent of all physical considerations. Data model is built using the information in users requirements specification. Source of information for next logical design phase. Copyright 2007 BUPTSSE Guo Wenming Page Phases of Database Design Step: Conceptual database design Step 1 Identify entity types Step 2 Identify relationship types Step 3 Identify and associate attributes with entity or relationship types Step 4 Determine attribute domains Step 5 Determine candidate and primary key attributes Step 6 Consider use of enhanced modeling concepts (optional step) Step 7 Check model for redundancy Step 8 Validate local conceptual model against user transactions Step 9 Review local conceptual data model with user Example for conceptual design: see P327 Copyright 2007 BUPTSSE Guo Wenming Page Phases of Database Design Logical database design: the process of constructing a model of the information used in an enterprise based on a specific data model (e.g. relational), but independent of a particular DBMS and other physical considerations. Conceptual data model is refined and mapped on to a logical data model. The logical data model is based on the target data model for the database (such as relational data model). The logical model also serves an important role during the operational maintenance stage to application lifecycle. Copyright 2007 BUPTSSE Guo Wenming Page Phases of Database Design Step: Logical database design for the relational model 1. Build and validate local logical data model for each view Step 1.1 Remove features not compatible with the relational model (optional step) Step 1.2 Derive relations for local logical data model Step 1.3 Validate relations using normalization Step 1.4 Validate relations against user transactions Step 1.5 Define integrity constraints Step 1.6 Review local logical data model with user 2. Build and validate global logical data model Step 2.1 Merge local logical data models into global model Step 2.2 Validate global logical data model Step 2.3 Check for future growth Step 2.4 Review global logical data model with users Example for logical design: see P342 Copyright 2007 BUPTSSE Guo Wenming Page Phases of Database Design Physical database design: The process of producing a description of the database implementation on secondary storage. It describes the base relations, file organizations, and indexes used to achieve efficient access to the data, any associated integrity constraints and security measures. Physical design is tailored to a specific DBMS system. The main aim of physical design is to describe how we intend to physically implement the logical design. There is feedback between physical and logical design. Because decisions are taken during physical design for improving performance that may affect the structure of the logical data model. Copyright 2007 BUPTSSE Guo Wenming Page Phases of Database Design Step: Physical database design for the relational model Step 1 Translate global logical data model for target DBMS Step 1.1 Design base relations Step 1.2 Design representation of derived data Step 1.3 Design enterprise constraints Step 2 Design physical representation Step 2.1 Analyze transactions Step 2.2 Choose file organization Step 2.3 Choose indexes Step 2.4 Estimate disk space requirements Step 3 Design user views Step 4 Design security mechanisms Step 5 Consider the introduction of controlled redundancy Step 6 Monitor and tune the operational system Example for physical design: see P371 Copyright 2007 BUPTSSE Guo Wenming Page 42 7

8 7.6.3 Phases of Database Design The correspondence between the three-level ANSI-SPARC architecture for a database system and conceptual, logical, and physical design. Copyright 2007 BUPTSSE Guo Wenming Page DBMS selection DBMS Selection: The Selection of an appropriate DBMS to support the database application. Selection can be done at any time prior to logical design provided sufficient information is available regarding system requirements such as performance, ease of restructuring, security, and integrity constraints. Main steps to selecting a DBMS: define Terms of Reference of study; shortlist two or three products; evaluate products; recommend selection and produce report. Copyright 2007 BUPTSSE Guo Wenming Page 44 Features for DBMS evaluation. 7.7 DBMS selection Features for DBMS evaluation. 7.7 DBMS selection Copyright 2007 BUPTSSE Guo Wenming Page 45 Copyright 2007 BUPTSSE Guo Wenming Page Application Design Application design: The design of user interface and application programs that use and process the database. Database and application design are parallel activities. Application includes two important activities: transaction design; user interface design. Transaction: An action, or series of actions, carried out by a single user or application program, which accesses or changes content of the database. Transactions refer real world events such as: the registering of a property for rent, the addition of a new member of staff, the registration of a new client, the renting out of a property. 7.8 Application Design The purpose of transaction design is to define and document the high-level characteristics of the transactions required, including: data to be used by the transaction; functional characteristics of the transaction; output of the transaction; importance to the users; expected rate of usage. Three main types of transactions: Retrieval transaction: to retrieve data for display on the screen or in the production of a report. Uupdate transaction: to insert new records, delete old records, or modify existing records in the database. Mixed transaction: involve both the retrieval and updating of data. Copyright 2007 BUPTSSE Guo Wenming Page 47 Copyright 2007 BUPTSSE Guo Wenming Page 48 8

9 7.8 Application Design User interface design guidelines Meaningful title Comprehensible instructions Logical grouping and sequencing of fields Visually appealing layout of the form/report Familiar field labels Consistent terminology and abbreviations Consistent use of color Visible space and boundaries for data-entry fields Convenient cursor movement Error correction for individual characters and entire fields Error messages for unacceptable values Optional fields marked clearly Explanatory messages for fields Completion signal Copyright 2007 BUPTSSE Guo Wenming Page Prototyping Prototyping: Building a working model of a database application. to identify features of a system that work well, or are inadequate; to suggest improvements or even new features; to clarify the users requirements; to evaluate feasibility of a particular system design. There are two prototyping strategies in common use today: Requirements prototyping: once the requirements are complete the prototype is discarded. Evolutionary prototyping: the prototype is not discarded but with further development becomes the working database application. Copyright 2007 BUPTSSE Guo Wenming Page Implementation Implementation: the physical realization of the database and application designs. The database implementation is achieved using DDL or a graphical user interface (GUI), Use DDL to create database schemas and empty database files, using DDL to create any specified user views. The application programs are implemented using 3GL or 4GL. This will include the database transactions implemented using the DML, possibly embedded in a host programming language. We also implement the other components of the application design such as menu screens, data entry forms, and reports. Copyright 2007 BUPTSSE Guo Wenming Page Data Conversion and Loading Data conversion and loading: Transferring any existing data into new database and converting any existing applications to run on new database. Only required when new database system is replacing an old system. DBMS normally has utility that loads existing files into new database. The utility requires the specification of the source file and the target database, and then automatically converts. May be possible for the developer to convert and use application programs from old system for use by new system. Copyright 2007 BUPTSSE Guo Wenming Page Testing Testing: the process of executing application programs with intent of finding errors. Use carefully planned test strategies and realistic data so that the entire testing process is methodically and rigorously carried out. Demonstrates that database and application programs appear to be working according to requirements. Testing cannot show absence of faults; it can show only that software faults are present. If real data is to be used, it is essential to have backups taken in case of error Operational Maintenance Operational Maintenance: the process of monitoring and maintaining system following installation. Maintenance involves the following activities: Monitoring the performance of the system: if performance falls below an acceptable level, may require tuning or reorganization of the database. Maintaining and upgrading database application (when required): new requirements are Incorporated into database application through the preceding stages of the lifecycle. Copyright 2007 BUPTSSE Guo Wenming Page 53 Copyright 2007 BUPTSSE Guo Wenming Page 54 9

10 7.14 CASE Tools Computer-Aided Software Engineering (CASE) can be applied to any tool that supports software engineering. CASE Support may include: data dictionary to store information about database application s data; design tools to support data analysis; tools to permit development of corporate data model, and conceptual and logical data models; tools to enable prototyping of applications. CASE tools may be divided into three categories Upper-CASE: support initial stages of lifecycle. Lower-CASE: support latter stage of lifecycle. integrated-case: support all stages of lifecycle. Copyright 2007 BUPTSSE Guo Wenming Page CASE Tools Application of CASE tools Copyright 2007 BUPTSSE Guo Wenming Page CASE Tools CASE tools provide following benefits: Standards: help to enforce standards on software project or across the organization. Integration: store all the definition generated in a repository, or data dictionary. The data then can be linked together to ensure that all parts of the system are integrated. support for standard methods: simply result in documentation that is correct and more current. Consistency: check all information consistency. automation: can automatically transform parts of a design specification into executable code. Copyright 2007 BUPTSSE Guo Wenming Page DA and DBA Data Administrator (DA) and Database Administrator (DBA) are responsible for managing and controlling activities associated with corporate data and corporate database, respectively. DA is more concerned with early stages of lifecycle and DBA is more concerned with later stages. Copyright 2007 BUPTSSE Guo Wenming Page DA and DBA DA: Management of data resource including: database planning, development and maintenance of standards, policies and procedures, and conceptual and logical database design. DBA: Management of physical realization of a database application including: physical database design and implementation, setting security and integrity controls, monitoring system performance, and reorganizing the database. Copyright 2007 BUPTSSE Guo Wenming Page 59 Question and Exercises? 1. Describe the major components of an information system. 2. Describe the main purpose(s) and activities associated with each stage of the database application lifecycle. 3. Compare and contrast the three phases of database design. 4. Identify the stage(s) where it is appropriate to select a DBMS and describe an approach to selecting the best DBMS. 5. Application design involves transaction design and user interface design. Describe the purpose and main activities associated with each. 6. Describe the main advantages of using the prototyping approach when building a database application. 7. Define the purpose and tasks associated with data administration and database administration. Copyright 2007 BUPTSSE Guo Wenming Page 60 10

11 Chapter 8. Entity-Relationship Modeling To ensure that we get a precise understanding of the nature of the data and how it is used by the enterprise, we need to have a model for communication that is non-technical and free of ambiguities. The Entity-Relationship (ER) model is one such example. ER modeling is an important technique for any database designer to master and forms the basis of the methodology. In this chapter we introduce the basic concepts of the ER model. Copyright 2007 BUPTSSE Guo Wenming Page 61 Chapter 8. Entity-Relationship Modeling We have chosen a diagrammatic notation that uses an increasingly popular object-oriented modeling language called Unified Modeling Language (UML). 8.1 Entity Types 8.2 Relationship Types 8.3 Attributes 8.4 String and Weak Entity Types 8.5 Attributes on relationship 8.6 Structural Constraints 8.7 Transform ER into relationship Copyright 2007 BUPTSSE Guo Wenming Page 62 Chapter 8. Entity-Relationship Modeling How to use Entity Relationship (ER) modeling in database design. Basic concepts associated with ER model. Diagrammatic technique for displaying ER model using Unified Modeling Language (UML). How to build an ER model from a requirements specification. How to derive a set of relations from a conceptual data model. Copyright 2007 BUPTSSE Guo Wenming Page 63 Chapter 8. Entity-Relationship Modeling Concepts of the ER Model Entity types Oxford Relationship types University Attributes Student Has Bill, Cain, Tim, Kitty, Copyright 2007 BUPTSSE Guo Wenming Page 64 Chapter 8. Entity-Relationship Modeling ER Diagram of Branch View of DreamHome Copyright 2007 BUPTSSE Guo Wenming Page Entity Types Entity type: A group of objects with same properties, which are identified by the enterprise as having an independent existence. The basic concept of the ER model is entity type. Different designer may identify different entities. Entity occurrence: A Uniquely identifiable object of an entity type. We identify each entity type by a name and a list of properties. We use the more general term entity where meaning is entity type or entity occurrence. Copyright 2007 BUPTSSE Guo Wenming Page 66 11

12 8.1 Entity Types A database normally contains many different entities. Examples of entities with a physical or conceptual existence. 8.1 Entity Types Diagrammatic representation of entity types Each entity type is shown as a rectangle labeled with the name of the entity. Normally a entity is named using singular noun. In UML, the first letter of each word in the entity name is upper case. Example for diagrammatic of the Staff and Branch entity types Copyright 2007 BUPTSSE Guo Wenming Page 67 Copyright 2007 BUPTSSE Guo Wenming Page Relationships Types Relationship type: A set of meaningful associations among entity types. A relationship type is a set of associations between one or more participating entity types. Each relationship type is given a name that describes its function. Relationship occurrence: A uniquely identifiable association, which includes one occurrence from each participating entity type. Relationship occurrence indicates the particular entity occurrences that are related. Copyright 2007 BUPTSSE Guo Wenming Page Relationships Types Diagrammatic representation of relationship types Each relationship type is shown as a line connecting the associated entity types, labeled with the name of the relationship. Normally, a relationship is named using a verb or a short phrase including a verb. An arrow symbol is placed beside the name indicating the correct directon. The first letter of each word in the relationship name is shown in upper case. Whenever possible, a relationship name should be unique for given ER model. Copyright 2007 BUPTSSE Guo Wenming Page Relationships Types A diagrammatic representation of Branch Has Staff relationship type. Relationship is only labeled in one direction. 8.2 Relationships Types Degree of a Relationship Type: The number of participating entities in relationship. The degree of a relationship indicates the number of entity types involved in a relationship. Relationship of degree: two is called binary; three is called ternary; four is called quaternary. Copyright 2007 BUPTSSE Guo Wenming Page 71 Copyright 2007 BUPTSSE Guo Wenming Page 72 12

13 8.2 Relationships Types Diagrammatic representation of complex relationships The UML notation uses a diamond to represent relationships with degrees higher than binary. The name of the relationship is displayed inside the diamond and in this case the directional arrow normally associated with the name is omitted. An example of a binary relationship called POwns. 8.2 Relationships Types An example of a ternary relationship called Registers. An example of a quaternary relationship called Arranges. Copyright 2007 BUPTSSE Guo Wenming Page 73 Copyright 2007 BUPTSSE Guo Wenming Page Relationships Types Recursive Relationship: A relationship type where same entity type participates more than once in different roles. Relationships may be given role names to indicate purpose that each participating entity type plays in a relationship. Role names can be important for recursive relationship to determine the function of each participant. Role names may also be used when two entities are associated through more than one relationship. Role names are usually not required if the function of the participating entities in a relationship is unambiguous. Copyright 2007 BUPTSSE Guo Wenming Page Relationships Types An example of a recursive relationship called Supervises with role names Supervisor and Supervisee. Copyright 2007 BUPTSSE Guo Wenming Page Relationships Types An example of entities associated through two distinct relationships called Manages and Has with Role Names. Copyright 2007 BUPTSSE Guo Wenming Page Attributes Attribute: A property of an entity or a relationship type. The attributes hold values that describe each entity occurrence and represent the main part of the data stored in the database. Attribute Domain: The Set of allowable values for one or more attributes. The domain defines the potential values that an attribute may hold and is similar to the domain concept in the relationship model. Attribute may share a domain. A fully developed data model includes the domains of each attribute in the ER model. Copyright 2007 BUPTSSE Guo Wenming Page 78 13

14 8.3 Attributes Attributes can be classified as being: Simple or Composite Single-valued or multi-valued Derived Simple Attribute: An attribute composed of a single component with an independent existence. Simple attributes can not be further subdivided into smaller components. Simple attributes are sometimes called atomic attributes. Composite Attribute: An attribute composed of multiple components, each with an independent existence. Copyright 2007 BUPTSSE Guo Wenming Page Attributes Single-valued Attribute: An attribute that holds a single value for each occurrence of an entity type. The majority of attributes are single-valued. For example: branchno is referred to as being singlevalued. Multi-valued Attribute: An attribute that holds multiple values for each occurrence of an entity type. A multi-valued attribute may have a set of numbers with upper and lower limits. Foe example: telno has between one and three values. Copyright 2007 BUPTSSE Guo Wenming Page Attributes Derived Attribute: An attribute that represents a value that is derivable from value of a related attribute or set of attributes, not necessarily in the same entity type. For example: duration can be calculated from the rentstart and rentfinish, which come from same entity type Lease. totalstaff can be calculated by counting the total number of Staff entity occurrences. deposit of the Lease entity can be calculated by twice the monthly rent of the PropertyForRent entity type. Copyright 2007 BUPTSSE Guo Wenming Page Attributes Candidate Key: The minimal set of attributes that uniquely identifies each occurrence of an entity type. A candidate key cannot contain a null. Primary Key: The candidate key that is selected to uniquely identify each occurrence of an entity type. The choice of primary key for an entity is based on attribute length, minimal number of attributes required. Composite Key: A candidate key that consists of two or more attributes. In some case, the key of an entity type is composed of several attributes, whose values together are unique for each entity occurrence but not separately. Copyright 2007 BUPTSSE Guo Wenming Page Attributes Diagrammatic representation of attributes If an entity type is to be displayed with its attribute, we divide the rectangle representing the entity in two. The upper part of the rectangle display the name of the entity and the lower part lists the names of the attributes. Copyright 2007 BUPTSSE Guo Wenming Page Strong and Weak Entity Types Strong Entity Type: An entity type that is not existence-dependent on some other entity type. A characteristic of a strong entity types is that each entity occurrence is uniquely identifiable using the primary key attribute(s). Weak Entity Type: An entity type that is existence-dependent on some other entity type. Each weak entity occurrence cannot be uniquely identified using only the attributes associated with that entity type. No primary key. Weak entity are sometimes referred to as child, dependent, or subordinate, and strong entity as parent, owner, or dominant. Copyright 2007 BUPTSSE Guo Wenming Page 84 14

15 8.4 Strong and Weak Entity Types For example: Strong Entity Type called Client and Weak Entity Type called Preference 8.5 Attribute on Relationships We use the same symbol, rectangle to represent attribute on a relationship, but the rectangle using a dashed line. Relationship called Advertises with Attributes. Copyright 2007 BUPTSSE Guo Wenming Page 85 Copyright 2007 BUPTSSE Guo Wenming Page Structural Constraints All appropriate enterprise constraints are identified and represented is an important part of modeling an enterprise. Main type of constraint on relationships is called multiplicity. Multiplicity: The number (or range) of possible occurrences of an entity type that may relate to a single occurrence of an associated entity type through a particular relationship. Multiplicity constrains the way that entities are related. Represents policies (called business rules) established by user or company. Copyright 2007 BUPTSSE Guo Wenming Page Structural Constraints The most common degree for relationships is binary. Binary relationships are generally referred to as being: one-to-one (1:1): a member of staff manages a branch; one-to-many (1:*): a member of staff oversees properties for rent; many-to-many (*:*): newspapers advertise properties for rent. It is important to note that not all enterprise constraints can be easily represented in an ER model. Copyright 2007 BUPTSSE Guo Wenming Page Structural Constraints How to determine the multiplicity for each of these constraints and how to represent each in an ER diagram, and how to examine multiplicity for relationships of degrees higher than binary One-to-One (1:1) Relationships One-to-Many (1:*) Relationships Many-to-Many (*:*) Relationships Multiplicity for Complex Relationships Cardinality and Participation Constraints Copyright 2007 BUPTSSE Guo Wenming Page One-to-One (1:1) Relationships Semantic Net of Staff Manages Branch Relationship Type. Copyright 2007 BUPTSSE Guo Wenming Page 90 15

16 8.6.1 One-to-One (1:1) Relationships Multiplicity of Staff Manages Branch (1:1) Relationship Type One-to-Many(1:*) Relationships Semantic Net of Staff Oversees PropertyForRent Relationship Type. Copyright 2007 BUPTSSE Guo Wenming Page 91 Copyright 2007 BUPTSSE Guo Wenming Page One-to-Many(1:*) Relationships Multiplicity of Staff Oversees PropertyForRent (1:*) Relationship Type Many-to-Many(*:*) Relationships Semantic Net of Newspaper Advertises PropertyForRent Relationship Type. Copyright 2007 BUPTSSE Guo Wenming Page 93 Copyright 2007 BUPTSSE Guo Wenming Page Many-to-Many(*:*) Relationships Multiplicity of Newspaper Advertises PropertyForRent (*:*) Relationship. Copyright 2007 BUPTSSE Guo Wenming Page Multiplicity for Complex Relationships Multiplicity for Complex Relationships: The number (or range) of possible occurrences of an entity type in an n-ary relationship when other (n-1) values are fixed. The multiplicity for a ternary relationship represents the potential range of entity occurrences of a particular entity in the relationship when the other two values representing the other two entities are fixed. For example, the ternary registers relationship between Staff, Branch, Client. We examine the registers relationship when the values for the Staff and Branch entities are fixed. Copyright 2007 BUPTSSE Guo Wenming Page 96 16

17 8.6.4 Multiplicity for Complex Relationships Semantic Net of Ternary Registers Relationship with Values for Staff and Branch Entities Fixed Multiplicity for Complex Relationships Multiplicity of Ternary Registers Relationship. When staffno and branchno are fixed the corresponding clienno are zero or more. Copyright 2007 BUPTSSE Guo Wenming Page 97 When staffno and clienno are fixed the corresponding branchno are 1 and 1. When branchno and clienno are fixed the corresponding staffno are 1 and 1. Copyright 2007 BUPTSSE Guo Wenming Page Multiplicity for Complex Relationships Summary of Multiplicity Constraints. Copyright 2007 BUPTSSE Guo Wenming Page Cardinality and Participation Constraint Multiplicity is made up of two types of restrictions on relationships: cardinality and participation. Cardinality: Describes maximum number of possible relationship occurrences for an entity participating in a given relationship type. The cardinality of a binary relationship is what we previously referred to as a one-to-one, one-to-many, many-to-many. Participation: Determines whether all or only some entity occurrences participate in a relationship. All refer to as mandatory participation. Only some refer to as optional participation. Copyright 2007 BUPTSSE Guo Wenming Page Cardinality and Participation Constraint Multiplicity as Cardinality and Participation Constraints Cardinality and Participation Constraint Multiplicity as Cardinality and Participation Constraints. Copyright 2007 BUPTSSE Guo Wenming Page 101 Copyright 2007 BUPTSSE Guo Wenming Page

18 8.7 Transform ER into relationship Local Conceptual Data Model for Staff View Showing all Attributes. 8.7 Transform ER into relationship Transform ER into relational data model: To create relations for the local logical data model to represent the entities, relationships, and attributes that have been identified. (1) Strong entity types Create a relation that includes all simple attributes of that entity. For composite attributes, include only constituent simple attributes. Staff (staffno, fname, lname, position, sex, DOB) Primary Key staffno (2) Weak entity types Create a relation that includes all simple attributes of that entity. Primary key is partially or fully derived from each owner entity. Preference (preftype, maxrent) Primary Key None (at present) Copyright 2007 BUPTSSE Guo Wenming Page 103 Copyright 2007 BUPTSSE Guo Wenming Page Transform ER into reationship (3) 1:* Binary relationship types Entity on one side is designated the parent entity and entity on many side is the child entity. Post copy of the primary key attribute(s) of parent entity into relation representing child entity, to act as a foreign key. Copyright 2007 BUPTSSE Guo Wenming Page Transform ER into reationship (4) 1:1 Binary relationship types More complex as cardinality cannot be used to identify parent and child entities in a relationship. Instead, participation used to decide whether to combine entities into one relation or to create two relations and post copy of primary key from one relation to the other. Consider following: (a) mandatory participation on both sides of 1:1 relationship; (b) mandatory participation on one side of 1:1 relationship; (c) optional participation on both sides of 1:1 relationship. (a) Mandatory participation on both sides of 1:1 relationship Combine entities involved into one relation and choose one of the primary keys of original entities to be primary key of new relation, while other (if one exists) is used as an alternate key. The Client States Preference relationship is an example of a 1:1 relationship with mandatory participation on both sides Client (clientno, fname, lname, telno, preftype, maxrent, staffno) Primary Key clientno Foreign Key staffno references Staff(staffNo) Copyright 2007 BUPTSSE Guo Wenming Page Transform ER into reationship (b) Mandatory participation on one side of a 1:1 relationship Identify parent and child entities using participation constraints. Entity with optional participation is designated parent entity, and other entity designated child entity. Copy of primary key of parent placed in relation representing child entity. If relationship has one or more attributes, these attributes should follow the posting of the primary key to the child relation. Example 8.7 Transform ER into reationship (c) Optional participation on both sides of a 1:1 relationship Designation of the parent and child entities is arbitrary unless can find out more about the relationship. Consider 1:1 Staff Uses Car relationship with optional participation on both sides. If there is no additional information to help select the parent and child entities, the choice is arbitrary. Designate car as parent, or vice versa. Assume majority of cars, but not all, are used by staff and only minority of staff use cars. The Car entity, although optional, is closer to being mandatory than Staff entity. Therefore designate Staff as parent entity and Car as child entity. Copyright 2007 BUPTSSE Guo Wenming Page 107 Copyright 2007 BUPTSSE Guo Wenming Page

19 8.7 Transform ER into reationship (5) 1:1 Recursive relationships - follow rules for participation for a 1:1 relationship. mandatory participation on both sides, represents the recursive relationship as a single relation with two copies of the primary key. As before, one copy of the primary key represents a foreign key and should be renamed to indicate the relationship it represents. mandatory participation on only one side: option to create a single relation with two copies of the primary key as described above, or create a new relation to represent the relationship. The new relation would only have two attributes, both copies of the primary key. As before, the copies of the primary keys act as foreign keys and have to be renamed to indicate the purpose of each in the relation. optional participation on both sides, again create a new relation as described above. 8.7 Transform ER into reationship (6) *:* Binary relationship types Create relation to represent relationship and include any attributes that are part of relationship. Post a copy of the primary key attribute(s) of the entities that participate in relationship into new relation, to act as foreign keys. These foreign keys will also form primary key of new relation, possibly in combination with some of the attributes of the relationship. Copyright 2007 BUPTSSE Guo Wenming Page 109 Copyright 2007 BUPTSSE Guo Wenming Page Transform ER into reationship (7) Complex relationship types Create relation to represent relationship and include any attributes that are part of the relationship. Post copy of primary key attribute(s) of entities that participate in the complex relationship into new relation, to act as foreign keys. Any foreign keys that represent a many relationship (for example, 1..*, 0..*) generally will also form the primary key of new relation, possibly in combination with some of the attributes of the relationship. 8.7 Transform ER into reationship (8) Multi-valued attributes Create new relation to represent multi-valued attribute and include primary key of entity in new relation, to act as a foreign key. Unless the multi-valued attribute is itself an alternate key of the entity, primary key of new relation is combination of the multivalued attribute and the primary key of the entity. Copyright 2007 BUPTSSE Guo Wenming Page 111 Copyright 2007 BUPTSSE Guo Wenming Page Transform ER into reationship 8.7 Transform ER into reationship Relations for the Staff views of Dreamhome. Copyright 2007 BUPTSSE Guo Wenming Page 113 Copyright 2007 BUPTSSE Guo Wenming Page

20 Question and Exercises? Question and Exercises? 1. Describe what entity types represent in an ER model and provide examples of entities with a physical or conceptual existence. 2. Describe what relationship types represent in an ER model and provide examples of unary, binary, ternary, and quaternary relationships. 3. Describe what attributes represent in an ER model and provide examples of simple, composite, single-value, multi-value, and derived attributes. 4. Describe what the multiplicity constraint represents for a relationship type. 5. What are enterprise constraints and how does multiplicity model these constraints? 6. Describe the rules for deriving relations that represent: strong entity types; weak entity types; one-to-many (1:*) binary relationship types; one-to-one (1:1) binary relationship types; one-to-one (1:1) recursive relationship types; many-to-many (*:*) binary relationship types; complex relationship types; multi-valued attributes. Copyright 2007 BUPTSSE Guo Wenming Page Create an ER diagram for each of the following descriptions: (a) Each company operates four departments, and each department belongs to one company. (b) Each department in part (a) employs one or more employees, and each employee works for one department. (c) Each of the employees in part (b) may or may not have one or more dependants, and each dependant belongs to one employee. (d) Each employee in part (c) may or may not have an employment history. (e) Represent all the ER diagrams described in (a), (b), (c), and (d) as a single ER diagram. Copyright 2007 BUPTSSE Guo Wenming Page 116 Question and Exercises? 7. You are required to create a conceptual data model of the data requirements for a company that specializes in IT training. The Company has 30 instructors and can handle up to 100 trainees per training session. The Company offers five advanced technology courses, each of which is taught by a teaching team of two or more instructors. Each instructor is assigned to a maximum of two teaching teams or may be assigned to do research. Each trainee undertakes one advanced technology course per training session. (a) Identify the main entity types for the company. (b) Identify the main relationship types and specify the multiplicity for each relationship. State any assumptions you make about the data. (c) Using your answers for (a) and (b), draw a single ER diagram to represent the data requirements for the company. Question and Exercises? 8. Derive relations for the following conceptual data model: Copyright 2007 BUPTSSE Guo Wenming Page 117 Copyright 2007 BUPTSSE Guo Wenming Page 118 Copyright 2007 BUPTSSE Guo Wenming Page 119 Copyright 2007 BUPTSSE Guo Wenming Page

21 Chapter 9 Normalization Main objective in developing a logical data model for relational database systems is to create an accurate representation of the data, its relationships, and constraints. A technique that we can use to help identify such relationship is called normalization. Normalization is a bottom-up approach to database design that begins by examining the relationships between attributes. We use a top-down approach to database design that begins by identifying the main entities and relationships and uses normalization as a validation technique. Copyright 2007 BUPTSSE Guo Wenming Page 121 Chapter 9 Normalization 9.1 The Purpose of Normalization 9.2 Data Redundancy and Update Anomalies 9.3 Functional Dependencies 9.4 The process of Normalization 9.5 First Normal Form (1NF) 9.6 Second Normal Form (2NF) 9.7 Third Normal Form (3NF) 9.8 General Definition of Second and Third Normal Form 9.9 Boyce-Codd Normal Form (BCNF) 9.10 Review of Normalization Copyright 2007 BUPTSSE Guo Wenming Page 122 Chapter 9 Normalization Purpose of normalization. Problems associated with redundant data. Identification of various types of update anomalies such as insertion, deletion, and modification anomalies. How to recognize appropriateness or quality of the design of relations. How functional dependencies can be used to group attributes into relations that are in a known normal form. How to undertake process of normalization. How to identify most commonly used normal forms, namely 1NF, 2NF, 3NF, and Boyce Codd normal form (BCNF). Copyright 2007 BUPTSSE Guo Wenming Page The Purpose of Normalization Normalization: A technique for producing a set of relations with desirable properties, given the data requirements of an enterprise. Four most commonly used normal forms are first (1NF), second (2NF) and third (3NF) normal forms, and Boyce Codd normal form (BCNF). Based on functional dependencies among the attributes of a relation. A relation can be normalized to a specific form to prevent possible occurrence of update anomalies. Copyright 2007 BUPTSSE Guo Wenming Page Data Redundancy and Update Anomalies Major aim of relational database design is to group attributes into relations to minimize data redundancy and reduce file storage space required by base relations. Problems associated with data redundancy are illustrated by comparing the following Staff and Branch relations with the StaffBranch relation. Copyright 2007 BUPTSSE Guo Wenming Page Data Redundancy and Update Anomalies StaffBranch relation has redundant data: details of a branch are repeated for every member of staff. In contrast, branch information appears only once for each branch in Branch relation and only branchno is repeated in Staff relation, to represent where each member of staff works. Copyright 2007 BUPTSSE Guo Wenming Page

Chapter 12. Entity-Relationship Modeling

Chapter 12. Entity-Relationship Modeling Chapter 12 Entity-Relationship Modeling Chapter 12 - Objectives How to use Entity Relationship (ER) modeling in database design. Basic concepts associated with ER model. Diagrammatic technique for displaying

More information

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations 1 Topics for this week: 1. Good Design 2. Functional Dependencies 3. Normalization Readings for this week: 1. E&N, Ch. 10.1-10.6; 12.2 2. Quickstart, Ch. 3 3. Complete the tutorial at http://sqlcourse2.com/

More information

Database Design Methodologies

Database Design Methodologies Critical Success Factors in Database Design Database Design Methodologies o Work interactively with the users as much as possible. o Follow a structured methodology throughout the data modeling process.

More information

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University Data Analysis 1 Unit 2.1 Data Analysis 1 - V2.0 1 Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship? Entities, attributes,

More information

not necessarily strictly sequential feedback loops exist, i.e. may need to revisit earlier stages during a later stage

not necessarily strictly sequential feedback loops exist, i.e. may need to revisit earlier stages during a later stage Database Design Process there are six stages in the design of a database: 1. requirement analysis 2. conceptual database design 3. choice of the DBMS 4. data model mapping 5. physical design 6. implementation

More information

Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model

Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Outline Using High-Level Conceptual Data Models for

More information

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University Data Analysis 1 SET08104 Database Systems Copyright @ Napier University Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship?

More information

Methodology Overview - Conceptual Database Design

Methodology Overview - Conceptual Database Design Methodology Overview - Conceptual Database Design Step 1 Build conceptual data model Step 1.1 Identify entity types Step 1.2 Identify relationship types (Use ER diagram) Step 1.3 Identify and associate

More information

Entity-Relationship Modeling

Entity-Relationship Modeling Concepts of the Entity-Relationship Model o Entity types Entity-Relationship Modeling o Relationship types o Attributes ER - 1 ER - 2 Entity Type An Example EER Model o Entity Type A type of objects or

More information

Objectives. Entity-Relationship Modeling. Entity Type. Concepts of the ER Model. Examples of Entity. Examples of Entity Types.

Objectives. Entity-Relationship Modeling. Entity Type. Concepts of the ER Model. Examples of Entity. Examples of Entity Types. Objectives Entity-Relationship Modeling The basic concepts associated with the Entity- Relationship (ER) model, a high-level conceptual data model. A diagrammatic technique for displaying an ER model.

More information

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 10 Outline The Role of Information Systems in

More information

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 10 Outline The Role of Information Systems in

More information

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps.

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps. DATABASE DESIGN - The ability to design databases and associated applications is critical to the success of the modern enterprise. - Database design requires understanding both the operational and business

More information

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E)

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E) THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E) 2 LECTURE OUTLINE Using High-Level, Conceptual Data Models for Database Design Entity-Relationship (ER) model Popular high-level conceptual

More information

IV. The (Extended) Entity-Relationship Model

IV. The (Extended) Entity-Relationship Model IV. The (Extended) Entity-Relationship Model The Extended Entity-Relationship (EER) Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of EER Diagrams

More information

Entity-Relationship Model. Modeling. Entity-Relationship Model. How do we design the database for an application?

Entity-Relationship Model. Modeling. Entity-Relationship Model. How do we design the database for an application? How do we design the database for an application? Entity-Relationship Model Dr. McNamara CSCI 371 Databases Fall 2006 1. Conceptual Design: Analyze the problem. Identify the entities, relationships, and

More information

Modern Database Management, 12e (Hoffer) Chapter 2 Modeling Data in the Organization

Modern Database Management, 12e (Hoffer) Chapter 2 Modeling Data in the Organization Modern Database Management, 12e (Hoffer) Chapter 2 Modeling Data in the Organization 1) The logical representation of an organization's data is called a(n): A) database model. B) entity-relationship model.

More information

From ER (or EER ) to Relational Schema. Inputs :ER Outputs: Data Model

From ER (or EER ) to Relational Schema. Inputs :ER Outputs: Data Model Mapping Rules From ER (or EER ) to Relational Schema Inputs :ER Outputs: Data Model Prentice Hall, 2002 1 Transforming EER Diagrams into Relations Mapping Regular Entities to Relations 1. Simple attributes:

More information

Modern Systems Analysis and Design

Modern Systems Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring System Requirements: Conceptual Data Modeling 10.1 Copyright 2002 Prentice-Hall,

More information

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model Chapter Outline Overview of Database Design Process Example Database Application (COMPANY) ER Model Concepts Entities and Attributes Entity

More information

Chapter 10. Practical Database Design Methodology. The Role of Information Systems in Organizations. Practical Database Design Methodology

Chapter 10. Practical Database Design Methodology. The Role of Information Systems in Organizations. Practical Database Design Methodology Chapter 10 Practical Database Design Methodology Practical Database Design Methodology Design methodology Target database managed by some type of database management system Various design methodologies

More information

CSE 412/598 DATABASE MANAGEMENT COURSE NOTES 3. ENTITY-RELATIONSHIP CONCEPTUAL MODELING

CSE 412/598 DATABASE MANAGEMENT COURSE NOTES 3. ENTITY-RELATIONSHIP CONCEPTUAL MODELING DATABASE MANAGEMENT COURSE NOTES 3. ENTITY-RELATIONSHIP CONCEPTUAL MODELING Department of Computer Science & Engineering Arizona State University 2 Quality of Conceptual Schema Correctness. No syntactic

More information

Data Modeling Part 1. CS 122: Database Systems Second Semester,

Data Modeling Part 1. CS 122: Database Systems Second Semester, Data Modeling Part 1 CS 122: Database Systems Second Semester, 2012-2013 Objectives Define key terms Write good names and definitions for entities, relationships, and attributes Identify relationship types

More information

Modern Systems Analysis and Design

Modern Systems Analysis and Design Modern Systems Analysis and Design Prof. David Gadish Structuring System Data Requirements Learning Objectives Concisely define each of the following key data modeling terms: entity type, attribute, multivalued

More information

Data Model ing Essentials

Data Model ing Essentials Data Model ing Essentials Third Edition Graeme C. Simsion and Graham C. Witt MORGAN KAUFMANN PUBLISHERS AN IMPRINT OF ELSEVIER AMSTERDAM BOSTON LONDON NEW YORK OXFORD PARIS SAN DIEGO SAN FRANCISCO SINGAPORE

More information

Database Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB

Database Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB Outline Database concepts Conceptual Design Logical Design Communicating with the RDBMS 2 Some concepts Database: an

More information

Database Systems - Introduction to Databases and Data Warehouses. Copyright (c) 2014 Pearson Education, Inc.

Database Systems - Introduction to Databases and Data Warehouses. Copyright (c) 2014 Pearson Education, Inc. Database Systems - Introduction to Databases and Data Warehouses Copyright (c) 2014 Pearson Education, Inc. INTRODUCTION Entity-relationship (ER) modeling - conceptual database modeling technique Enables

More information

Chapter 10 Structuring System Requirements: Conceptual Data Modeling. Copyright 2002 Prentice-Hall, Inc.

Chapter 10 Structuring System Requirements: Conceptual Data Modeling. Copyright 2002 Prentice-Hall, Inc. Chapter 10 Structuring System Requirements: Conceptual Data Modeling 10.1 Copyright 2002 Prentice-Hall, Inc. Learning Objectiveses 10.2 Define key data modeling terms Entity type Attribute Multivalued

More information

Database Design Methodology

Database Design Methodology Database Design Methodology Three phases Database Design Methodology Logical database Physical database Constructing a model of the information used in an enterprise on a specific data model but independent

More information

The Entity Relationship Model

The Entity Relationship Model The Entity Relationship Model CC414- Lec 3 Prof. Dr. Amani Saad Database Systems, 8 th Edition 1 CC414- Prof. Dr. Amani Saad From: Database Systems, Coronel. 1 Objectives In this lecture, you will learn:

More information

Q4. What are data model? Explain the different data model with examples. Q8. Differentiate physical and logical data independence data models.

Q4. What are data model? Explain the different data model with examples. Q8. Differentiate physical and logical data independence data models. FAQs Introduction to Database Systems and Design Module 1: Introduction Data, Database, DBMS, DBA Q2. What is a catalogue? Explain the use of it in DBMS. Q3. Differentiate File System approach and Database

More information

Chapter 6 The Relational Algebra and Relational Calculus

Chapter 6 The Relational Algebra and Relational Calculus Chapter 6 The Relational Algebra and Relational Calculus Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 6 Outline (cont d.) Examples of Queries in Relational Algebra

More information

Database Systems Conceptual Database Design SL04

Database Systems Conceptual Database Design SL04 Informatik für Ökonomen II Fall 2010 Database Systems Conceptual Database Design SL04 Basic Entity-Relationship (ER) Model Concepts Entities and attributes, entity types, entity sets Relationships and

More information

IT2305 Database Systems I (Compulsory)

IT2305 Database Systems I (Compulsory) Database Systems I (Compulsory) INTRODUCTION This is one of the 4 modules designed for Semester 2 of Bachelor of Information Technology Degree program. CREDITS: 04 LEARNING OUTCOMES On completion of this

More information

Foundations of Information Management

Foundations of Information Management Foundations of Information Management - WS 2012/13 - Juniorprofessor Alexander Markowetz Bonn Aachen International Center for Information Technology (B-IT) Data & Databases Data: Simple information Database:

More information

2. Conceptual Modeling using the Entity-Relationship Model

2. Conceptual Modeling using the Entity-Relationship Model ECS-165A WQ 11 15 Contents 2. Conceptual Modeling using the Entity-Relationship Model Basic concepts: entities and entity types, attributes and keys, relationships and relationship types Entity-Relationship

More information

Lesson 8: Introduction to Databases E-R Data Modeling

Lesson 8: Introduction to Databases E-R Data Modeling Lesson 8: Introduction to Databases E-R Data Modeling Contents Introduction to Databases Abstraction, Schemas, and Views Data Models Database Management System (DBMS) Components Entity Relationship Data

More information

Chapter 3 Data Modeling Using the Entity-Relationship Modeling

Chapter 3 Data Modeling Using the Entity-Relationship Modeling Chapter 3 Data Modeling Using the Entity-Relationship Modeling Multiple-Choice Questions: 1) is an object modeling methodology. a) EML b) UML c) OML d) DML 2) diagrams are important part of object modeling

More information

DATABASE MANAGEMENT SYSTEMS. Question Bank:

DATABASE MANAGEMENT SYSTEMS. Question Bank: DATABASE MANAGEMENT SYSTEMS Question Bank: UNIT 1 1. Define Database? 2. What is a DBMS? 3. What is the need for database systems? 4. Define tupule? 5. What are the responsibilities of DBA? 6. Define schema?

More information

Lecture 12: Entity Relationship Modelling

Lecture 12: Entity Relationship Modelling Lecture 12: Entity Relationship Modelling The Entity-Relationship Model Entities Relationships Attributes Constraining the instances Cardinalities Identifiers Generalization 2004-5 Steve Easterbrook. This

More information

1. What are the main building modules of the Entity Relationship model? Discuss each one.

1. What are the main building modules of the Entity Relationship model? Discuss each one. 1. What are the main building modules of the Entity Relationship model? Discuss each one. Let s begin by reviewing that working within a RDBMS model, using entity relationship modeling (ERM) forms the

More information

www.gr8ambitionz.com

www.gr8ambitionz.com Data Base Management Systems (DBMS) Study Material (Objective Type questions with Answers) Shared by Akhil Arora Powered by www. your A to Z competitive exam guide Database Objective type questions Q.1

More information

Chapter 4. Entity Relationship (ER) Modeling. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel

Chapter 4. Entity Relationship (ER) Modeling. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel Chapter Entity Relationship (ER) Modeling Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel 1 In this chapter, you will learn: How relationships between entities

More information

Entity-Relationship (ER) Model

Entity-Relationship (ER) Model ER Design (1) Entity-Relationship (ER) Model Elements in a database: data entries Data entries represent Entities: data objects, e.g., students, courses, and instructors Relationships among entities: students

More information

IT2304: Database Systems 1 (DBS 1)

IT2304: Database Systems 1 (DBS 1) : Database Systems 1 (DBS 1) (Compulsory) 1. OUTLINE OF SYLLABUS Topic Minimum number of hours Introduction to DBMS 07 Relational Data Model 03 Data manipulation using Relational Algebra 06 Data manipulation

More information

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model The entity-relationship (E-R) model is a a data model in which information stored

More information

Database Design Methodology

Database Design Methodology Topic 7 Database Design Methodology LEARNING OUTCOMES When you have completed this Topic you should be able to: 1. Discuss the purpose of a design methodology. 2. Explain three main phases of design methodology.

More information

Database Systems - Introduction to Databases and Data Warehouses. Copyright (c) 2014 Pearson Education, Inc.

Database Systems - Introduction to Databases and Data Warehouses. Copyright (c) 2014 Pearson Education, Inc. Database Systems - Introduction to Databases and Data Warehouses Copyright (c) 2014 Pearson Education, Inc. INTRODUCTION Relational database model - logical database model that represents a database as

More information

Chapter 14. Normalization

Chapter 14. Normalization Chapter 14 Normalization Materials To Have Handy A paper copy of the StaffBranch relation (pg. 369 of the textbook and on or about slide 9) A paper copy of the Staff Branch function dependencies (pg. 375

More information

Designing a Database Schema

Designing a Database Schema Week 10: Database Design Database Design From an ER Schema to a Relational One Restructuring an ER schema Performance Analysis Analysis of Redundancies, Removing Generalizations Translation into a Relational

More information

CTEC323 Lecture 6. Dan Zingaro OISE/UT. October 9, 2008

CTEC323 Lecture 6. Dan Zingaro OISE/UT. October 9, 2008 CTEC323 Lecture 6 Dan Zingaro OISE/UT October 9, 2008 Entity-Relationship Model Entity-relationship model (ERM) is a conceptual model, independent of the type of database It can be used to generate a relational

More information

DATABASE SYSTEMS. Chapter 5 Entity Relationship (ER) Modelling DESIGN IMPLEMENTATION AND MANAGEMENT INTERNATIONAL EDITION ROB CORONEL CROCKETT

DATABASE SYSTEMS. Chapter 5 Entity Relationship (ER) Modelling DESIGN IMPLEMENTATION AND MANAGEMENT INTERNATIONAL EDITION ROB CORONEL CROCKETT DATABASE SYSTEMS DESIGN IMPLEMENTATION AND MANAGEMENT INTERNATIONAL EDITION ROB CORONEL CROCKETT Chapter 5 Entity Relationship (ER) Modelling 1 (Rob, Coronel & Crockett 978184480731) In this chapter, you

More information

Kathleen Durant CS3200 Lecture 2

Kathleen Durant CS3200 Lecture 2 Entity Relationship Model (ERM) Kathleen Durant CS3200 Lecture 2 1 What is the goal of Modeling? Derive a logical description of our data. Understand the various ways in which the data is used. Identify

More information

2. Entity-Relationship Model

2. Entity-Relationship Model 2. Entity-Relationship Model Entity-relationship model describes data involves in real world in terms of object and their relationships. It is widely used for initial database design. It describes overall

More information

Entity-Relationship Model

Entity-Relationship Model UNIT -2 Entity-Relationship Model Introduction to ER Model ER model is represents real world situations using concepts, which are commonly used by people. It allows defining a representation of the real

More information

! A database can be modeled as: ! An entity is an object that exists and is distinguishable from other. ! Entities have attributes

! A database can be modeled as: ! An entity is an object that exists and is distinguishable from other. ! Entities have attributes Chapter 2: Entity-Relationship Model Entity Sets! Entity Sets! Relationship Sets! Design Issues! Mapping Constraints! Keys! E-R Diagram! Extended E-R Features! Design of an E-R Database Schema! Reduction

More information

Database Design. October 24, 2008. Database Design

Database Design. October 24, 2008. Database Design October 24, 2008 Outline E-R diagrams Represent logical structure simply, clearly Rectangles: entity sets Ellipses: attributes Diamonds: relationship sets Lines: linking elements Double ellipse: multi-valued

More information

Database Management System

Database Management System Database Management System For Computer Science & Information Technology By www.thegateacademy.com Syllabus Syllabus for Data Base Management System E Model, elational Model, elational Algebra, Tuple Calculus,

More information

Chapter 5. Entity-Relationship Modeling (Continued) Lecture 8. Structural Constraints. Two main types of restrictions on relationships are:

Chapter 5. Entity-Relationship Modeling (Continued) Lecture 8. Structural Constraints. Two main types of restrictions on relationships are: Lecture 8 Chapter 5 Entity-Relationship Modeling (Continued) Structural Constraints Two main types of restrictions on relationships are: Cardinality Constraints Participation Constraints 1 Cardinality

More information

ACSC223: Database Systems

ACSC223: Database Systems The E-R Model ACSC223: Database Systems The Entity-Relationship (E-R) model is used as a first step in database design. Lecture 2: Entity-Relationship Model Harris Papadopoulos A database can be modelled

More information

Systems Analysis and Design

Systems Analysis and Design Systems Analysis and Design Slides adapted from Jeffrey A. Hoffer, University of Dayton Joey F. George, Florida State University Joseph S. Valacich, Washington State University Modern Systems Analysis

More information

Chapter 2: Entity-Relationship Model. Entity Sets. " Example: specific person, company, event, plant

Chapter 2: Entity-Relationship Model. Entity Sets.  Example: specific person, company, event, plant Chapter 2: Entity-Relationship Model! Entity Sets! Relationship Sets! Design Issues! Mapping Constraints! Keys! E-R Diagram! Extended E-R Features! Design of an E-R Database Schema! Reduction of an E-R

More information

1) List the summary of the notations for ER diagrams. Include symbols used in ER diagram and their meaning. 8 Marks (Jun / July2014)

1) List the summary of the notations for ER diagrams. Include symbols used in ER diagram and their meaning. 8 Marks (Jun / July2014) Question Paper Solutions UNIT-2 1) List the summary of the notations for ER diagrams. Include symbols used in ER diagram and their meaning. 8 Marks (Jun / July2014) 2) With respect to ER model explain

More information

The Entity-Relationship Diagram

The Entity-Relationship Diagram The Entity-Relationship Diagram Overview of Database Design Conceptual design: (ER Model is used at this stage.) What are the entities and relationships in the enterprise? What information about these

More information

DATABASE NORMALIZATION

DATABASE NORMALIZATION DATABASE NORMALIZATION Normalization: process of efficiently organizing data in the DB. RELATIONS (attributes grouped together) Accurate representation of data, relationships and constraints. Goal: - Eliminate

More information

Chapter (3) Data Modeling Using the Entity-Relationship Model

Chapter (3) Data Modeling Using the Entity-Relationship Model Chapter (3) Data Modeling Using the Entity-Relationship Model Objectives Presenting the role of high-level conceptual data models in database design. Understanding the traditional approach of concentrating

More information

BCA. Database Management System

BCA. Database Management System BCA IV Sem Database Management System Multiple choice questions 1. A Database Management System (DBMS) is A. Collection of interrelated data B. Collection of programs to access data C. Collection of data

More information

HNDIT 1105 Database Management Systems

HNDIT 1105 Database Management Systems HNDIT 1105 Database Management Systems Lesson 02: Database Design Process & ER Diagrams By S. Sabraz Nawaz M.Sc. In IS (SLIIT), PGD in IS (SLIIT), BBA (Hons.) Spl. in IS (SEUSL), MIEEE, MAIS Senior Lecturer

More information

Chapter 5: Logical Database Design and the Relational Model Part 1: Transforming EER Diagrams into Relations Modern Database Management 6 th Edition

Chapter 5: Logical Database Design and the Relational Model Part 1: Transforming EER Diagrams into Relations Modern Database Management 6 th Edition Chapter 5: Logical Database Design and the Relational Model Part 1: into Relations Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Robert C. Nickerson ISYS

More information

SKIP Ch.6. Database System Concepts, 6 th Ed. Silberschatz, Korth and Sudarshan See for conditions on re-use

SKIP Ch.6. Database System Concepts, 6 th Ed. Silberschatz, Korth and Sudarshan See  for conditions on re-use SKIP Ch.6 Database System Concepts, 6 th Ed. See www.db-book.com for conditions on re-use Chapter 7: DB Design and the Entity-Relationship (ER) Model Database System Concepts, 6 th Ed. See www.db-book.com

More information

Dr. Rafiq Zakaria Campus. Maulana Azad College of Arts, Science & commerce, Aurangabad. Department of Computer Science. Academic Year

Dr. Rafiq Zakaria Campus. Maulana Azad College of Arts, Science & commerce, Aurangabad. Department of Computer Science. Academic Year Dr. Rafiq Zakaria Campus Maulana Azad College of Arts, Science & commerce, Aurangabad Department of Computer Science Academic Year 2015-16 MCQs on Database Management System Using SQL Sem. :- IV Q.1 DBMS

More information

Relational Database Systems Part 01. Karine Reis Ferreira

Relational Database Systems Part 01. Karine Reis Ferreira Relational Database Systems Part 01 Karine Reis Ferreira karine@dpi.inpe.br Database System Database: is a collection of related data. represents some aspect of the real world is a logically coherent collection

More information

Aveek Gupta, CISA. IPCC Paper 7A: Information Technology Chapter 2

Aveek Gupta, CISA. IPCC Paper 7A: Information Technology Chapter 2 Aveek Gupta, CISA IPCC Paper 7A: Information Technology Chapter 2 * DBMS/RDBMS 1 Administration 2 3 4 5 6 6 7 Models DML and DDL Data Dictionaries Distributed DataBases Object Oriented DataBases Client

More information

Database Concepts. Database & Database Management System. Application examples. Application examples

Database Concepts. Database & Database Management System. Application examples. Application examples Database & Database Management System Database Concepts Database = A shared collection of logically related (and a description of this data), designed to meet the information needs of an organization.

More information

2. Basic Relational Data Model

2. Basic Relational Data Model 2. Basic Relational Data Model 2.1 Introduction Basic concepts of information models, their realisation in databases comprising data objects and object relationships, and their management by DBMS s that

More information

Concepts of Database Management Seventh Edition. Chapter 6 Database Design 2: Design Method

Concepts of Database Management Seventh Edition. Chapter 6 Database Design 2: Design Method Concepts of Database Management Seventh Edition Chapter 6 Database Design 2: Design Method Objectives Discuss the general process and goals of database design Define user views and explain their function

More information

XV. The Entity-Relationship Model

XV. The Entity-Relationship Model XV. The Entity-Relationship Model The Entity-Relationship Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of E-R Diagrams and Business Rules The

More information

14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to:

14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to: 14 Databases 14.1 Source: Foundations of Computer Science Cengage Learning Objectives After studying this chapter, the student should be able to: Define a database and a database management system (DBMS)

More information

Normalization. Purpose of normalization Data redundancy Update anomalies Functional dependency Process of normalization

Normalization. Purpose of normalization Data redundancy Update anomalies Functional dependency Process of normalization Normalization Purpose of normalization Data redundancy Update anomalies Functional dependency Process of normalization 1 Purpose of Normalization Normalization is a technique for producing a set of suitable

More information

Normalization. Normalization. Normalization. Data Redundancy

Normalization. Normalization. Normalization. Data Redundancy Normalization Normalization o Main objective in developing a logical data model for relational database systems is to create an accurate representation of the data, its relationships, and constraints.

More information

Files. Files. Files. Files. Files. File Organisation. What s it all about? What s in a file?

Files. Files. Files. Files. Files. File Organisation. What s it all about? What s in a file? Files What s it all about? Information being stored about anything important to the business/individual keeping the files. The simple concepts used in the operation of manual files are often a good guide

More information

Chapter 2: Entity-Relationship Model

Chapter 2: Entity-Relationship Model Chapter 2: Entity-Relationship Model Entity Sets Relationship Sets Design Issues Mapping Constraints Keys E R Diagram Extended E-R Features Design of an E-R Database Schema Reduction of an E-R Schema to

More information

Chapter 2: Entity-Relationship Model. E-R R Diagrams

Chapter 2: Entity-Relationship Model. E-R R Diagrams Chapter 2: Entity-Relationship Model What s the use of the E-R model? Entity Sets Relationship Sets Design Issues Mapping Constraints Keys E-R Diagram Extended E-R Features Design of an E-R Database Schema

More information

A brief overview of developing a conceptual data model as the first step in creating a relational database.

A brief overview of developing a conceptual data model as the first step in creating a relational database. Data Modeling Windows Enterprise Support Database Services provides the following documentation about relational database design, the relational database model, and relational database software. Introduction

More information

Outlines. Data Modeling Using the Entity- Relationship Model. ER Model Concepts. Database Design Process. Entities and attributes

Outlines. Data Modeling Using the Entity- Relationship Model. ER Model Concepts. Database Design Process. Entities and attributes Outlines Data Modeling Using the Entity- Relationship Model Instructor: Chapter 6 Churee Techawut 1) Database design process 2) ER Model concepts 3) ER diagrams notation 4) Relationships and relationship

More information

Course Notes on The Bases of the Relational Model

Course Notes on The Bases of the Relational Model Course Notes on The Bases of the Relational Model Intuitive View of Relations Popular view of the relational model = information is structured as 2-dimensional tables of simple values (with lines, or rows,

More information

Database Management Systems

Database Management Systems Database Management Systems Database Design (1) 1 Topics Information Systems Life Cycle Data Base Design Logical Design Physical Design Entity Relationship (ER) Model Entity Relationship Attributes Cardinality

More information

Databases. Jörg Endrullis. VU University Amsterdam

Databases. Jörg Endrullis. VU University Amsterdam Databases Jörg Endrullis VU University Amsterdam 2015 Database Design Database Design formal model of the relevant aspects of the real word mini world universe of disclosure the real world serves as measure

More information

Basic Database Concepts

Basic Database Concepts Tore Risch Uppsala University, Sweden UDBL Basic Database Concepts What is a database? A database is a collection of related data stored in a computer managed by a DBMS. What is a DBMS, Database Management

More information

Concepts of Database Management, Fifth Edition. Chapter 6: Database Design 2: Design Methodology

Concepts of Database Management, Fifth Edition. Chapter 6: Database Design 2: Design Methodology Concepts of Database Management, Fifth Edition Chapter 6: Database Design 2: Design Methodology Objectives Discuss the general process and goals of database design Define user views and explain their function

More information

three Entity-Relationship Modeling chapter OVERVIEW CHAPTER

three Entity-Relationship Modeling chapter OVERVIEW CHAPTER three Entity-Relationship Modeling CHAPTER chapter OVERVIEW 3.1 Introduction 3.2 The Entity-Relationship Model 3.3 Entity 3.4 Attributes 3.5 Relationships 3.6 Degree of a Relationship 3.7 Cardinality of

More information

ETEC 2601 Database Systems

ETEC 2601 Database Systems ETEC 2601 Database Systems Chapter 5: Data Modeling With The Entity-Relationship Model Copyright 2004-2010 J. B. Gallaher The Data Model The design of a database Is the way the user conceives the information

More information

E n t i t y R e l a t i o n s h i p M o d e l

E n t i t y R e l a t i o n s h i p M o d e l E n t i t y R e l a t i o n s h i p M o d e l Entity Sets Relationship Sets Design Issues Mapping Constraints Keys E-R Diagram Extended E-R Features Design of an E-R Database Schema Reduction of an E-R

More information

Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No.

Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. # 1a Conceptual Design Hello in today session we would be looking

More information

Database Design and the Entity-Relationship Model

Database Design and the Entity-Relationship Model Database Design and the Entity-Relationship Model Computer Science 460/660 Boston University Fall 2013 David G. Sullivan, Ph.D. Database Design In database design, we determine: which data fields to include

More information

Chapter 2. Data Model. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel

Chapter 2. Data Model. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel Chapter 2 Data Model Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel 1 In this chapter, you will learn: Why data models are important About the basic data-modeling

More information

B2.2-R4: INTRODUCTION TO DATABASE MANAGEMENT SYSTEM

B2.2-R4: INTRODUCTION TO DATABASE MANAGEMENT SYSTEM B2.2-R4: INTRODUCTION TO DATABASE MANAGEMENT SYSTEM NOTE: 1. There are TWO PARTS in this Module/Paper. PART ONE contains FOUR questions and PART TWO contains FIVE questions. 2. PART ONE is to be answered

More information

CHAPTER 6 DATABASE MANAGEMENT SYSTEMS. Learning Objectives

CHAPTER 6 DATABASE MANAGEMENT SYSTEMS. Learning Objectives CHAPTER 6 DATABASE MANAGEMENT SYSTEMS Management Information Systems, 10 th edition, By Raymond McLeod, Jr. and George P. Schell 2007, Prentice Hall, Inc. 1 Learning Objectives Understand the hierarchy

More information

Entity-Relationship Model. Database Modeling (Part 1) Entity. Entity-Relationship Model EMPLOYEE

Entity-Relationship Model. Database Modeling (Part 1) Entity. Entity-Relationship Model EMPLOYEE Entity-Relationship Model Database Modeling (Part 1) A conceptual data model, which is a representation of the structure of a database that is independent of the software that will be used to implement

More information

CSC 742 Database Management Systems

CSC 742 Database Management Systems CSC 742 Database Management Systems Topic #4: Data Modeling Spring 2002 CSC 742: DBMS by Dr. Peng Ning 1 Phases of Database Design Requirement Collection/Analysis Functional Requirements Functional Analysis

More information