Data Models - PowerPoint PPT Presentation

data models n.
Skip this Video
Loading SlideShow in 5 Seconds..
Data Models PowerPoint Presentation
Download Presentation
Data Models

play fullscreen
1 / 40
Data Models
Download Presentation
Download Presentation

Data Models

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Data Models

  2. Overview • Why data models are important • Basic data-modeling building blocks • What are business rules and how do they influence database design • How the major data models evolved • How data models can be classified by level of abstraction

  3. Importance of Data Models • Data models • Representations, usually graphical, of complex real-world data structures • Facilitate interaction among the designer, the applications programmer and the end user • End-users have different views and needs for data • Data model organizes data for various users

  4. Data Model Basic Building Blocks • Entity • Anything about which data will be collected/stored • Attribute • Characteristic of an entity • Relationship • Describes an association among entities • One-to-one (1:1) relationship • One-to-many (1:M) relationship • Many-to-many (M:N or M:M) relationship • Constraint • A restriction placed on the data

  5. Business Rules • Brief, precise and unambiguous descriptions of policies, procedures or principles within the organization • Apply to any organization that stores and uses data to generate information • Description of operations that help to create and enforce actions within that organization’s environment

  6. Business Rules (continued) • Must be put in writing • Must be kept up to date • Sometimes external to the organization • Must be easy to understand and widely disseminated • Describe characteristics of the data as viewed by the company

  7. Discovering Business Rules • Company managers • Policy makers • Department managers • Written documentation • Procedures • Standards • Operations manuals • Direct interviews with end users

  8. Translating Business Rules to Data Model Components • Standardize company’s view of data • Communication tool between users and designers • Allow designer to understand the nature, role and scope of data • Allow designer to understand business processes • Allow designer to develop appropriate relationship participation rules and constraints • Promote creation of an accurate data model • Nouns translate into entities • Verbs translate into relationships among entities • Relationships are bi-directional

  9. The Evolution of Data Models We will look briefly at each Model Type

  10. The Hierarchical Model • Developed in 1960s to manage large amounts of data for complex manufacturing projects • Logical structure represented as an upside-down “tree” • Hierarchical structure contains levels or segments • Depicts a set of one-to-many (1:M) relationships • Between a parent and it’s children segments • Each parent can have many children • each child has only one parent

  11. Hierarchical Model • Advantages • Many features form the foundation for current data models • Generated a large installed base of programmers • Who developed solid business applications • Disadvantages • Complex to implement • Difficult to manage • Lacks structural independence • Implementation limitations • Lack of standards (Company vs Industry or Open)

  12. The Network Model • Resembles hierarchical model • Difference child can have multiple parents • Collection of records in 1:M relationships • Set – Relationship of at least two record types • Owner – Equivalent to the hierarchical model’s parent • Member – Equivalent to the hierarchical model’s child

  13. Network Model Terms • Schema • Conceptual organization of entire database • As viewed by the database administrator • Subschema • Defines database as “seen” by the application programs • Schema Data Definition Language (DDL) • Enables database administrator to define schema components • Subschema Data Definition Language (DDL) • Allows applications to define database components to be used • Data Management Language (DML) • Defines the environment in which data can be managed • Works with the data in the database

  14. Network Model • Advantages • Represents complex data relationships better than Hierarchical Model • Improved database performance • Impose a database “industry” standard • Conference on Data Systems Languages (CODASYL) • Database Task Group (DBTG) • Disadvantages • Too cumbersome • Lack of “ad hoc” query capability • Put heavy pressure on programmers • Any structural change in the database could produce havoc in all application programs that drew data from the database

  15. The Relational Model • Conceptually simple – Linked Tables • Developed by Edgar F. Codd (IBM 1970 ) • Considered ingenious but impractical in 1970 • Computers lacked power to implement the relational model • Today’s PCs run sophisticated relational databases

  16. Relational Model – Tables • Also called relations • Matrix of row and column intersections • Stores a collection of similar entities • Resembles a file or spreadsheet • Purely logical structure • How data are physically stored is of no concern to the user or the designer • The source of a real database revolution

  17. Relational Model – Relational Diagram • Representation of relational database’s • Entities (Tables) • Attributes within those entities (Fields) • Relationships between those entities (Links)

  18. Relational Model – RDBMS • Relational Database Management System • All the system components • User interface • Tables • Method of querying the tables • Performs same basic functions as • Hierarchical and • Network DBMS models • Plus many other functions • Most important –hides the complexities of the relational model from the user

  19. The Relational Model – SQL • Structured Query Language (SQL) • Allows ad hoc queries – questions of the data • User can specify what must be done without specifying how it must be done • Dominance due in great part to its powerful and flexible query language • SQL-based relational database application: • User interface • A set of tables stored in the database • SQL engine

  20. Entity Relationship Model (ERM) • Introduced by Peter Chen in 1976 • Widely accepted and adapted graphical tool for data modeling • Graphical representation of entities and their relationships in a database structure

  21. Entity Relationship Model – Terms • Entity Relationship Diagram (ERD) • Graphic representations to model database components • Entity is mapped to a relational table • Entity instance (or occurrence) – A row in table • Entity set (table) – Collection of like entities • Connectivity labels • Diamond connected to related entities through a relationship line • Types of relationships

  22. ERM Notation Symbols • Three symbols to represent element relationships • Ring represents "zero" • Dash represents "one" • Crow's foot represents "more" or "many" • Used in pairs to represent the four types of relationships • Ring and dash → zero or one • Dash and dash → exactly one • Ring and crow's foot → zero or more • Dash and crow's foot → one or more

  23. The Object Oriented (OO) Model • Models both data and their relationships in a single structure known as an object • Object described by its factual content • Like relational model’s entity • Includes info about relationships between facts within object and relationships with other objects • Unlike relational model’s entity

  24. Object Oriented Model – Terms • Object-oriented data model (OODM) • Semantic data model • Basis of object-oriented database management system (OODBMS) • Evolved to allow an object to also contain all operations • Object – abstraction of a real-world entity • Basic building block for autonomous structures • Attributes – properties of an object • Class - objects that share similar • Classes are organized in a class hierarchy • Inheritance – an object within the class hierarchy inherits the attributes and methods of class

  25. Extended Relational Data Model (ERDM) • Semantic data model • Developed in response to increasing complexity of applications • Based heavily on relational model • Relational DB response to OODM • Primarily geared to business applications • Typically scientific or engineering apps • Object/relational database management system (O/RDBMS) • DBMS based on the ERDM

  26. Object Role Modeling (ORM)

  27. ORM • Not to be confused with Object-relational mapping • Provides a conceptual approach to modeling • Models the application area or universe of discourse (UoD) • Relevant set of entities that are being dealt with by quantifiers • Requires a good understanding of the UoD • Means of specifying this understanding in a clear, unambiguous way • Simplifies design process with natural language and intuitive diagrams • Can be populated with examples • Evolved from the Natural language Information Analysis Method • Mid-1970s • G. M. Nijssen and Dr. Terry Halpin first joint papers in 1989 • Capable of capturing many business rules typically unsupported in other popular data modeling notations • Software tool support include Microsoft Visio for Enterprise Architects, CaseTalk, Infagon and NORMA

  28. Database Models and the Internet • Internet drastically changed role and scope of database market • Growing need to manage unstructured information • The data found in today’s: • Online documents • Web pages • Most modern DBMS incorporate Internet-age technologies such as Extended Markup Language (XML) support

  29. Data Models: Summary • Each new data model capitalized on the shortcomings of previous models • Common characteristics: • Conceptual simplicity without compromising the semantic completeness of the database • Represent the real world as closely as possible • Representation of real-world transformations (behavior) must comply with consistency and integrity characteristics of any data model

  30. Data Models: Summary

  31. Degrees of Data Abstraction • Way of classifying data models • Many processes begin at high level of abstraction • Proceed to an ever-increasing level of detail • Designing a usable database follows the same basic process

  32. Degrees of Data Abstraction • American National Standards Institute (ANSI) • Standards Planning and Requirements Committee (SPARC) • Developed standards 1970 • Framework for data modeling based on degrees of data abstraction: • External • Conceptual • Internal • Physical

  33. The External Model • Each end users’ view of the data environment • Modeler subdivides requirements and constraints into functional (Business unit’s) modules • These can be examined within the framework of their external models

  34. External Model – Advantages • Easy to identify specific data required to support each business unit’s operations • Facilitates designer’s job by providing feedback about the model’s adequacy • Creation of external models helps to identify and ensure security constraints in the database design • Simplifies application program development

  35. The Conceptual Model (1 of 2) • Global view of the entire database • Representation of data as viewed by the entire organization • Basis for identification and high-level description of main data objects, avoiding details

  36. The Conceptual Model (2 of 2) • Software and hardware independent • Independent of DBMS software • Independent of hardware to be used • Changes in either hardware or DBMS software have no effect on the database design at the conceptual level • Most widely used conceptual model is the Entity Relationship (ER) model • Provides a relatively easily understood macro level view of data environment

  37. The Internal Model • The database as “seen” by the DBMS • Maps the conceptual model to the DBMS • Depicts a specific representation of an internal model • Logical independence • Can change the internal model without affecting the conceptual model

  38. The Physical Model • Lowest level of abstraction • Describes the way data are saved on storage media such as disks or tapes • Software and hardware dependent • Requires database designers to have a detailed knowledge of the hardware and software used to implement database design • Physical independence • Can change the physical model without affecting the internal model

  39. Degrees of Data Abstraction - Summary