Database Systems: Design, Implementation, and Management

1. Database Systems: Design, Implementation, and Management Chapter 2 Data Models

2. Objectives In this chapter, you will learn: • About data modeling and why data models are important • About the basic data-modeling building blocks • What business rules are and how they influence database design • How the major data models evolved • How data models can be classified by level of abstraction

3. Models and data models

4. What is a model? • A model is a simplified way to describe or explain a complex reality • A model helps people communicate and work simply yet effectively when talking about and manipulating complex real-world phenomena

5. Scientific models Sources: http://www.redorbit.com/education/reference_library/space_1/universe/2574692/geocentric_model/ http://hendrianusthe.wordpress.com/2012/06/21/heliocentric-vs-geocentric/

6. Conceptual models Sources: http://info563.malagaclasses.info/strategy-it-2/ http://fivewhys.wordpress.com/2012/05/22/business-model-innovation/

7. Importance of Data Models

8. Business Rules

9. Sources of Business Rules

10. The Evolution of Data Models

11. Obsolete models:Hierarchical and network models

12. The Relational Model • Uses key concepts from mathematical relations (tables) • “Relational” in “relational model” means “tables” (mathematical relations), not “relationships” • Table (relations) • Matrix consisting of row/column intersections • Relations have well defined methods (queries) for combining their data members • Selecting (reading) and joining (combining) data is defined based on rigorous mathematical principles • Relational data management system (RDBMS) • Relations where originally too advanced for 1970s computing power • As computing power increased, simplicity of the model prevailed

14. The Entity Relationship Model • Very detailed specification of relationships and their properties • Enhancement of the relational model • Relations (tables) become entities • Entity relationship diagram (ERD) • Uses graphic representations to model database components • Many variations for notation exist; we will use the Crow’s Foot notation

16. The Object-Oriented Data Model (OODM) • Addresses “impedance mismatch” problem of the ER model • The ER model’s view of data (tables) and programmers’ view of data (objects in OOP), is completely different • This mismatch makes database programming painful, especially for very complex data structures • OODM Uses object-oriented programming concepts to store data • Objects represent nouns (entities or records) • Objects have attributes (properties or fields) with values (data) • Objects have methods (operations or functions) • Classes group similar objects using a hierarchy and inheritance • In an OODBMS, the data retrieval and storage closely mirrors the data structures that programmers use, and so programming complex objects is much easier than with the ER model • More advanced forms support the Extended Relational Data Model, Object/Relational DBMS, and XML data structures

17. OODBMS vs. RDBMS • https://www.youtube.com/watch?v=kORTgvfHl4g

18. Explaining Big Data https://www.youtube.com/watch?v=7D1CQ_LOizA

19. Big Data • Volume • Huge (terabytes and petabytes) amounts of data, especially from the Internet • Velocity • Organizations need to process the huge amounts of data rapidly, just as with smaller databases • Variety • Wide variety of data, much of it unstructured and even changing in structure

20. Big data’s solutions and RDBMS’s failure • Scale up: use more powerful servers • RDBMS is very computing intensive • More data requires much faster, more capable, expensive computers, and even that’s not good enough for big data • Scale out: use many cheap distributed servers • RDBMS doesn’t work rapidly with distributed processing • Consistency is the biggest problem: guaranteeing consistency (which RDBMS is great at) is slow, too slow for big data

21. What is NoSQL? https://www.youtube.com/watch?v=qUV2j3XBRHc

22. NoSQL Databases to the Big Data rescue • “NoSQL” means: • Non-relational or non-RDBMS • Also “Not only SQL”—a few do support SQL • It is not one model; it is many different models that are not relational • High scalability • Support distributed database architectures • High availability • Rapid performance for big data, including unstructured and sparse data • Fault tolerance • Continue to work even if some servers in the cluster fail • Geared toward performance rather than transaction consistency • Store data in key-value stores

23. Disadvantages of NoSQL • Complex programming is required • “NoSQL” means you lose the ease-of-use benefits of SQL • There is often no relationship support in the database—you have to program relationships in code • There is no transaction integrity support • The data you retrieve at any given moment might be wrong… but it will eventually become OK • This is the price to pay for rapid performance in a distributed database

25. Which data model should you use? • Hierarchical or network models • Obsolete—no one uses these any longer • Entity-relationship model • Continuation or enhancement of the relational model • 90% or more of professional database situations • Object-oriented database • When you have very complex data structures, you need rapid performance, and it makes business sense (***) • Data structures are so complex that organizing data as tables causes headaches in programming retrieval and storage • NoSQL • Vast amounts of unstructured data where you need rapid performance • Speed is more important than data consistency

26. Degrees of Data Abstraction

27. Figure 2.7 - Data Abstraction Levels

28. Figure 2.8 - External Models for Tiny College

29. Figure 2.9 - Conceptual Model for Tiny College

30. Figure 2.10 - Internal Model for Tiny College

31. The Physical Model