Skip to main content Accessibility help

We use cookies to distinguish you from other users and to provide you with a better experience on our websites. Close this message to accept cookies or find out how to manage your cookie settings.

Close cookie message
×
  1. Home
  2. Browse subjects
  3. Computer Science
  4. Knowledge Management, Databases and Data Mining
  5. Content listing

Refine search

Refine search

Access:
Content type:
Publication date:
Apply   From and To filters
Subject: Show more
Journals Show more
Publishers: Show more
Societies Show more
Series: Show more
Collections: Show more

Actions for selected content:

Select all | Deselect all
  • View selected items
  • Export citations
  • Download PDF (zip)
  • Save to Kindle
  • Save to Dropbox
  • Save to Google Drive

Save Search

You can save your searches here and later view and run them again in "My saved searches".

Please provide a title, maximum of 40 characters.
Cancel
×

1550 results in Knowledge Management, Databases and Data Mining

Page 39 of 78

  • 6 - Relational Databases: The Relational Model

  • from Part II - Types of Database Systems
  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp 104-145

  • Summary

    Chapter Objectives

    In this chapter, you will learn to:

  • • understand the basic concepts of the relational model;

  • • differentiate between different types of keys and identify their role in the relational model;

  • • understand how normalization can be used to make sure a relational data model has no redundancies or inconsistencies;

  • • map a conceptual ER model to a relational model and identify any loss of semantics;

  • • map a conceptual EER model to a relational model and identify any loss of semantics.

    • Opening Scenario

    Starting from the EER conceptual data model developed in Chapter 3, Sober wants to proceed to the next step of database design. The company wants to map the EER model to a logical relational model and needs to understand what semantics gets lost in the mapping process.

    Relational databases implement the relational model, which is one of the most popular logical and internal data models in use nowadays. It was first formalized by Edgar F. Codd in his seminal paper “A relational model of data for large shared data banks”, which appeared in the well-respected journal Communications of the ACM in 1970. In this chapter we first introduce the basic concepts of the relational model and then formally define them in the next section. This is followed by an overview of the different types of keys, which are an essential building block of the relational model. The relational constraints are summarized next, followed by an example of a relational data model. Normalization will also be reviewed as a procedure to remove redundancies and anomalies from a relational data model. After having introduced the need for normalization and some informal guidelines, we zoom into functional dependencies and prime attribute types and discuss how both can be used during a multi-step normalization procedure. To conclude, we discuss how to map both ER and EER conceptual data models to a logical relational data model. The next chapter then zooms into SQL, which is the DDL and DML used by relational databases.

    Drill Down

    Edgar F. Codd was an English computer scientist (19 August 1923–18 April 2003) who laid the foundation of the relational model while working for IBM. He received the Turing Award in 1981 and was inducted as a Fellow of the Association for Computing Machinery (ACM) in 1994.

  • 14 - Basics of Transaction Management

  • from Part III - Physical Data Storage, Transaction Management, and Database Access
  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp 430-457

  • Summary

    Chapter Objectives

    In this chapter, you will learn to:

  • • understand the concepts of transactions, recovery, and concurrency control;

  • • identify the various steps of a transaction lifecycle as well as the DBMS components involved and the role of the logfile;

  • • discern different types of failures and how to deal with them;

  • • understand different types of concurrency problems as well as the importance of schedules, serial schedules, and serializable schedules;

  • • discern the differences between optimistic and pessimistic schedulers;

  • • grasp the importance of locking and locking protocols;

  • • understand the responsibility of the DBMS's transaction management facilities to ensure the ACID properties of a transaction.

    • Opening Scenario

    Since many users will interact simultaneously with Sober's database, the company wants to understand any problems that may occur. Furthermore, Sober also wants to mitigate the risks of various types of failures that may make its data incorrect.

    The majority of databases in actual organizational settings are multi-user databases. This implies that many applications and users can access the data in the database in parallel. This concurrent access to the same data, if not managed properly, may induce different types of anomalies or unexpected problems. Moreover, various kinds of errors or calamities may occur in the respective DBMS components or its environment – such as the operating system, the applications interacting with the DBMS, or the storage subsystem – possibly rendering the database data into an inconsistent state. Fortunately, most database systems provide a realm of transparent, although often configurable, solutions to avoid or otherwise deal with such problems. In this way, the DBMS supports the ACID (Atomicity, Consistency, Isolation, Durability) properties already mentioned in Chapter 1. At the heart of these solutions are the concepts of transactions and transaction management, recovery, and concurrency control. In this chapter, we first introduce each of these concepts. Then, we focus in more detail on transaction management and the DBMS components involved. After that, we discuss recovery and the different techniques to deal with calamities in the DBMS or application program, as well as the storage media. Finally, we describe in detail how concurrency control techniques, in interplay with transaction management and recovery, guarantee seamless concurrent access by multiple users to shared data.

  • 17 - Data Warehousing and Business Intelligence

  • from Part IV - Data Warehousing, Data Governance, and (Big) Data Analytics
  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp 551-589

  • Summary

    Chapter Objectives

    In this chapter, you will learn to:

  • • understand the differences between operational and tactical/strategic decision-making;

  • • define a data warehouse in terms of its key characteristics;

  • • discern different types of data warehouse schemas;

  • • understand the key steps of the extraction, transformation, and loading process;

  • • define a data mart in terms of its key characteristics;

  • • understand the advantages and disadvantages of virtual data warehouses and virtual data marts;

  • • define an operational data store;

  • • discern the differences between data warehouses and data lakes;

  • • understand the applications of business intelligence by means of query and reporting, pivot tables, and on-line analytical processing.

    • Opening Scenario

    In addition to using its data for day-to-day operational activities, Sober wants to leverage it for both tactical and strategical decision-making. More specifically, the company wants to get a thorough insight in its sales numbers and how these vary on a quarterly basis, per type of service (ride-hailing versus ride-sharing) and per type of car (Sober car or not). By doing so, Sober wants to better understand where it can grow and identify interesting opportunities. The company does not believe it can use its existing relational data model for this since turning the above questions into SQL queries might be too cumbersome. The principals think a new type of data structure is needed to more efficiently answer the above business questions. Considering the limitations of its current model, what would you recommend Sober to do?

    Until this point, we have largely focused on storing data in the most optimal way, ensuring their integrity, as much as possible, at all times. A next obvious question is what can we do with these data from a business perspective? In this chapter, we discuss how to take data and extract valuable new business insights from it. We start by zooming into the various levels of corporate decisionmaking and how this relates to data requirements that support these decisions. This will bring us to the concept of a data warehouse, a massive consolidated data store that we formally define and extensively discuss in terms of data model, design, and development. We contrast data warehousing with some newer developments, such as virtualization, data lakes, and indicate synergies.

  • 8 - Object-Oriented Databases and Object Persistence

  • from Part II - Types of Database Systems
  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp 207-230

  • Summary

    Chapter Objectives

    In this chapter, you will learn to:

  • • use advanced concepts of object orientation, such as method overloading, inheritance, method overriding, polymorphism, and dynamic binding;

  • • identify various strategies to ensure object persistence;

  • • understand the key components of an OODBMS;

  • • understand the ODMG standard and its object model;

  • • use the ODMG object definition language (ODL) to define object types;

  • • use the ODMG object query language (OQL) to formulate queries;

  • • implement the ODMG standard through language bindings;

  • • evaluate OODBMSs against RDBMSs.

    • Opening Scenario

    Sober has noted that many database applications are being developed using programming languages such as Java, Python, and C++. It found out that many languages are based on the object-oriented paradigm. The company wants to know what this entails and whether this could have any implications and/or potential for its database and choice of DBMS.

    The object-oriented (OO) paradigm was first introduced by programming languages such as C++, Eiffel, and Smalltalk. Due to its expressive modeling power and formal semantics, the principles of OO have also been widely used in software development methodologies. However, for data storage and management, the adoption of OO proved less straightforward. In this chapter, we discuss various approaches to object persistence. First, we refresh the basic concepts of OO, many of which have been covered in Chapter 3. This will be followed by a discussion of advanced OO concepts such as method overloading, inheritance, method overriding, polymorphism, and dynamic binding. Next, we review the basic principles of object persistence. We then discuss object-oriented database management systems (OODBMSs), which is the core of this chapter. We conclude with evaluating OODBMSs and demonstrating their impact on the emergence of object-relational mapping (ORM) frameworks, which facilitate the persistence of objects into RDBMSs. Due to its popularity and ease of use, we use Java as the OO language for the examples.

    Recap: Basic Concepts of OO

    In object-oriented (OO) programming, an application consists of a series of objects that request services from each other. Each object is an instance of a class that contains a blueprint description of all the object's characteristics. Contrary to procedural programming, an object bundles both its variables (which determine its state) and its methods (which determine its behavior) in a coherent way.

  • Preface

  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp xix-xxiii

  • Summary

    Congratulations! By picking up this book, you have made the first step in your journey through the wonderful world of databases. As you will see in this book, databases come in many different forms – from simple spreadsheets or other file-based attempts and hierarchical structures, to relational, object-oriented, and even graph-oriented ones – and are used across the world throughout a variety of industry sectors to manage, store, and analyze data.

    This book is the result of having taught an undergraduate database management class and a postgraduate advanced database management class for more than ten years. Throughout the years we have found no textbook that covers the material in a comprehensive way without becoming flooded by theoretical detail and losing focus. Hence, after we teamed up together, we decided to start writing a book ourselves. This work aims to offer a complete and practical guide covering all the governing principles of database management, including:

  • • end-to-end coverage, starting with legacy technologies to emerging trends such as Big Data, NoSQL databases, analytics, data governance, etc.;

  • • a unique perspective on how lessons learned from past data management could be relevant in today's technology setting (e.g., navigational access and its perils in CODASYL and XML/OO databases);

  • • a critical reflection and accompanying risk management considerations when implementing the technologies considered, based on our own experiences participating in data and analytics-related projects with industry partners in a variety of sectors, from banking to retail and from government to the cultural sector;

  • • a solid balance between theory and practice, including various exercises, industry examples and case studies originating from diverse and complementary business practices, scientific research, and academic teaching experience.

    • The book also includes an appendix explaining our “online playground” environment, where you can try out many concepts discussed in the book. Additional appendices, including an exam bank containing several cross-chapter questions and references to our YouTube lectures, are provided online as well.

    We hope you enjoy this book and that you, the reader, will find it a useful reference and trusted companion in your work, studies, or research when storing, managing, and analyzing small or Big Data!

    Who This Book is For

    We have tried to make this book complete and useful for both novice and advanced database practitioners and students alike.

  • 9 - Extended Relational Databases

  • from Part II - Types of Database Systems
  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp 231-254

  • Summary

    Chapter Objectives

    In this chapter, you will learn to:

  • • identify the shortcomings of the relational model;

  • • define and use triggers and stored procedures;

  • • understand how RDBMSs can be extended with OO concepts such as user-defined types, user-defined functions, inheritance, behavior, polymorphism, collection types, and large objects;

  • • define and use recursive SQL queries.

    • Opening Scenario

    Now that Sober has decided to continue with its relational model, the company was wondering whether it could enrich it with some smart extensions. It wondered whether it would be possible to make the RDBMS more active so it can autonomously take initiative for action when casespecific situations occur. Although Sober was not entirely convinced about OODBMSs and decided not to continue with them, they appreciate some of the OO concepts introduced. They are wondering whether it would be possible to have a best-of-both-worlds approach, whereby they could enrich their relational model with some of the OO concepts they learned about.

    In this chapter, we revisit RDBMSs, which are very popular in industry. We start by refreshing the key building blocks of the relational model and discuss its limitations. We then look at the ways of extending relational databases, starting with reviewing triggers and stored procedures as two key mechanisms to make RDBMSs more active. Next, we introduce object-relational DBMSs (ORDBMSs). In contrast to the OODBMSs in Chapter 8, ORDBMSs build on a relational engine, but they extend RDBMSs with object-oriented (OO) characteristics. We conclude with recursive queries, which are a powerful extension to the SQL language.

    Limitations of the Relational Model

    The relational data model, and the RDBMS implementations thereof, have been very successful for managing well-structured numerical and alphanumerical data. One of the major reasons for this is the mathematical simplicity and soundness of the relational model. As discussed in Chapter 6, its two key building blocks are tuples and relations. A tuple is a composition of values of attribute types that describe an entity. It can be created by using a tuple constructor. A relation is a mathematical set of tuples describing similar entities. It can be created by using a set constructor. As also mentioned in Chapter 6, the relational model requires all relations to be normalized. Data about entities can be fragmented across multiple relations, which are connected using primary–foreign key relationships.

  • 15 - Accessing Databases and Database APIs

  • from Part III - Physical Data Storage, Transaction Management, and Database Access
  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp 458-515

  • Summary

    Chapter Objectives

    In this chapter, you will learn:

  • • how database systems can be accessed from the outside world;

  • • what is meant by a database application programming interface (API);

  • • to understand the differences between proprietary versus universal APIs, between embedded versus call-level APIs, and early binding versus late binding;

  • • which universal database application programming interfaces are available to interact with database systems;

  • • how DBMSs play their role within the World Wide Web and the internet.

    • Opening Scenario

    Sober has decided on a relational DBMS vendor, has drawn up the relational schema to implement, and has verified that the database is working as planned by importing sample data and testing some SQL queries. However, a DBMS system does not live in isolation. Sober is planning to develop several applications that will have to connect to its DBMS. For instance, Sober is thinking about a website where customers can book cabs and retrieve their order history, and a mobile app that will have to fetch information from the DBMS. Finally, Sober is also planning to develop a desktop application for the customer support team that will be used internally, but also has to be able to access the same DBMS. Sober is still thinking about different options in terms of programming languages to develop these applications, but wonders how easy it will be for these applications to access the database in order to store and retrieve information from it.

    In this chapter, we take a closer look at the forms of accessing database systems. Naturally, the manner of how a DBMS is interfaced with heavily depends on the system architecture it applies. Accessing a DBMS in a legacy mainframe set-up is different than interfacing with a DBMS in a client–server-based architecture, so we open this chapter with an overview of different database system architectures. Next, we turn our attention toward the different database application programming interfaces, or APIs for short. As the name suggests, a database API exposes an interface through which clients, third-party, and end-user applications can access, query, and manage the DBMS. Finally, we look at DBMSs’ role and place within the World Wide Web, and how recent trends in this landscape are influencing and shaping the requirements imposed on DBMSs.

  • 19 - Big Data

  • from Part IV - Data Warehousing, Data Governance, and (Big) Data Analytics
  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp 626-663

  • Summary

    Chapter Objectives

    In this chapter, you will learn:

  • • what is meant by “Big Data” and its “5 Vs”;

  • • to understand the differences between traditional database management systems and Big Data technologies such as Hadoop;

  • • to understand the differences between traditional data warehousing approaches and Big Data technologies;

  • • to identify the tradeoffs when opting to adopt a Big Data stack;

  • • what the links are between Big Data and NoSQL databases.

    • Opening Scenario

    Sober has made its first steps in setting up a data warehouse on top of its existing DBMS stack to kick-start its business intelligence activities, with the main goal of reporting purposes. However, Sober's management is hearing a lot lately about “Big Data” and “Hadoop” with regards to storing and analyzing huge amounts of data. Sober is wondering whether these technologies would offer an added benefit. So far, Sober is happy with its relational DBMS, which integrates nicely with its business intelligence tooling. The mobile development team, meanwhile, has been happy to work with MongoDB, a NoSQL database, to handle the increased workload from mobile users. Hence, the question for Sober is: what would a Big Data stack offer on top of this?

    Data are everywhere. To give some staggering examples, IBM projects that every day we generate 2.5 quintillion bytes of data. Every minute, more than 300,000 tweets are created, Netflix subscribers are streaming more than 70,000 hours of video, Apple users download 30,000 apps, and Instagram users like almost two million photos. In relative terms, 90% of the data in the world have been created in the last two years. These massive amounts of data yield an unprecedented treasure of internal customer knowledge, ready to be analyzed using state-of-the-art analytical techniques to better understand and exploit customer behavior by identifying new business opportunities together with new strategies. In this chapter, we zoom into this concept of “Big Data” and explain how these huge data troves are changing the world of DBMSs. We kick-off by reviewing the 5 Vs of Big Data. Next, we zoom in on the common Big Data technologies in use today. We discuss Hadoop, SQL on Hadoop, and Apache Spark.

  • 3 - Conceptual Data Modeling Using the (E)ER Model and UML Class Diagram

  • from Part I - Databases and Database Design
  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp 38-78

  • Summary

    Chapter Objectives

    In this chapter, you will learn to:

  • • understand the different phases of database design: conceptual design, logical design, and physical design;

  • • build a conceptual data model using the ER model and understand the limitations thereof;

  • • build a conceptual data model using the EER model and understand the limitations thereof;

  • • build a conceptual data model using the UML class diagram and understand the limitations thereof.

    • Opening Scenario

    Sober has decided to invest in a new database and begin a database design process. As a first step, it wants to formalize the data requirements in a conceptual data model. Sober asks you to build both an EER and a UML data model for its business setting. It also wants you to extensively comment on both models and properly indicate their shortcomings.

    In this chapter we start by zooming out and reviewing the database design process. We elaborate on conceptual, logical, and physical database design. We continue the chapter with conceptual design, which aims at elucidating the data requirements of a business process in a formal way. We discuss three types of conceptual data models: the ER model; the EER model; and the UML class diagram. Each model is first defined in terms of its fundamental building blocks. Various examples are included for clarification. We also discuss the limitations of the three conceptual data models and contrast them in terms of their expressive power and modeling semantics. Subsequent chapters continue from the conceptual data models of this chapter and map them to logical and internal data models.

    Phases of Database Design

    Designing a database is a multi-step process, as illustrated in Figure 3.1. It starts from a business process. As an example, think about a B2B procurement application, invoice handling process, logistics process, or salary administration. A first step is requirement collection andanalysis, where the aim is to carefully understand the different steps and data needs of the process. The information architect (see Chapter 4) will collaborate with the business user to elucidate the database requirements. Various techniques can be used, such as interviews or surveys with end-users, inspections of the documents used in the current process, etc. During the conceptual design, both parties try to formalize the data requirements in a conceptual datamodel.

  • 12 - Physical File Organization and Indexing

  • from Part III - Physical Data Storage, Transaction Management, and Database Access
  • Wilfried Lemahieu, KU Leuven, Belgium, Seppe vanden Broucke, KU Leuven, Belgium, Bart Baesens, KU Leuven, Belgium
  • Book:
    Principles of Database Management
    Published online:
    17 August 2019
    Print publication:
    12 July 2018, pp 351-394

  • Summary

    Chapter Objectives

    In this chapter, you will learn to:

  • • grasp the basic principles of storage hardware and physical database design;

  • • understand how data items can be organized into stored records;

  • • identify various methods for primary and secondary file organization;

    • Opening Scenario

    Now that Sober has its relational logical data model from Chapter 6 ready, it wants to understand how it can be physically implemented. The company is also wondering whether there exist any physical means to speed up the response times of frequently used queries.

    This chapter focuses on the most important principles pertaining to the physical organization of records and files. As such, it can be considered as the prerequisite to Chapter 13, which applies these principles in the context of physical database organization. In this way Chapters 12 and 13 are complementary in covering all facets of physical database design – the translation of a logical data model into an internal data model, including the design of indexes to speed up data access.

    First, we present some overall properties of storage devices and the impact of the mechanicals of hard disk drives on the performance aspects of data retrieval. After that, we overview the mapping of logical modeling constructs onto physical concepts, and thus of the logical data model onto the internal model. Then, we briefly discuss record organization, covering the different alternatives to organize physical data records, consisting of individual data fields. After that comes the main body of this chapter, focusing on file organization and covering methods to organize records into physical files, as well as techniques to efficiently search for records with certain characteristics. We discuss several approaches, such as sequential files, hashing and the use of different index types, including B+-trees. Chapter 13 follows on from this chapter, applying the insights gained from the file organization section to the particular context of physical database organization.

    Storage Hardware and Physical Database Design

    Physical database design pertains to the design of an internal data model and to the way in which the logical database concepts discussed in the previous chapters are realized physically as stored records, physical files, and, ultimately, a physical database.

Principles of Database Management
  • The Practical Guide to Storing, Managing and Analyzing Big and Small Data
  • Wilfried Lemahieu, Seppe vanden Broucke, Bart Baesens
  • Published online:
    17 August 2019
    Print publication:
    12 July 2018
  • This comprehensive textbook teaches the fundamentals of database design, modeling, systems, data storage, and the evolving world of data warehousing, governance and more. Written by experienced educators and experts in big data, analytics, data quality, and data integration, it provides an up-to-date approach to database management. This full-color, illustrated text has a balanced theory-practice focus, covering essential topics, from established database technologies to recent trends, like Big Data, NoSQL, and more. Fundamental concepts are supported by real-world examples, query and code walkthroughs, and figures, making it perfect for introductory courses for advanced undergraduates and graduate students in information systems or computer science. These examples are further supported by an online playground with multiple learning environments, including MySQL, MongoDB, Neo4j Cypher, and tree structure visualization. This combined learning approach connects key concepts throughout the text to the important, practical tools to get started in database management.

Page 39 of 78