A database is an organized collection of data stored so that it can be efficiently retrieved, updated, and managed. Before we can compare database types or design one, we need a shared vocabulary: data versus information, records, fields, and tables, and the software layer — the database management system (DBMS) — that sits between users and the stored data. This topic builds that foundation.
This matters for everything that follows in COP4708. Later in the module you will distinguish relational, NoSQL, and hierarchical models and choose the right one for a given scenario. Those decisions only make sense once you can say precisely what a database is, what problems it solves that a spreadsheet does not, and what a DBMS actually does for you (storage, querying, concurrent access, security, and integrity).
As you watch, keep a running glossary. Note how each speaker defines a database, where tables, rows (records), and columns (fields) appear, and when the discussion shifts from the data itself to the DBMS that manages it. Also notice any mention of selection criteria — scalability, structure, consistency — since those terms return later in the module.
An overview video from IBM Technology that defines what a database is and explains how databases store and organize data for retrieval and management. Based on its title and framing, it is likely to walk through the basic purpose of databases, common types or categories, and the role of database software and services in making data usable. Expect whiteboard-style explanation with concrete examples.
It directly addresses the core subtopics of defining a database, its purpose, and the role of the DBMS, and it comes from a well-established enterprise technology producer whose explainer series is aimed at newcomers.
This video introduces the relational model, the most common way of organizing data in a database. From its title and description it is likely to cover tables made of rows and columns, how relationships between tables are expressed, and how SQL is used to query that structure. It serves as the natural next step after the general definition of a database.
It supplies the concrete vocabulary — tables, records, fields, and relationships — that this topic requires, and it anchors those terms in the relational systems used throughout the course.
ByteByteGo surveys how engineers decide which database to use for a given workload. Based on the title and channel focus on system design, it likely contrasts different database families and the criteria that drive the choice, such as data structure, query needs, and scale. It frames databases as a design decision rather than a single fixed tool.
It previews the comparison and selection work later in the module while reinforcing why a database, and a particular kind of database, is chosen in the first place; ByteByteGo is a widely used system design channel known for clear visual explanations.
Together these videos establish the vocabulary and conceptual base the module outcomes depend on. The IBM overview and the relational database video supply the definitions and terms — tables, records, fields, keys, and the DBMS — needed for MO1, and the relational video previews the structural thinking required to distinguish database models in MO2. The ByteByteGo video introduces the comparison criteria and decision-making mindset underlying MO3, MO4, and MO5, so that when you later evaluate database types for e-commerce, healthcare, banking, or social media scenarios, you are applying criteria you have already seen in context.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A relational database organizes information into tables made up of rows (records) and columns (fields). Each table describes one kind of thing — customers, orders, patients, courses — and a defined schema states what columns exist, what type of data each holds, and what rules the data must follow. Tables are connected to one another through keys: a primary key uniquely identifies each row in a table, and a foreign key in one table points to the primary key of another, creating a relationship the database itself can enforce.
This structure matters for the rest of the course because it is the baseline against which every other database model is compared. When we later look at NoSQL and hierarchical systems, the questions we ask — how rigid is the schema, how are relationships represented, how easily can we query across data sets, how well is data integrity protected — are questions that come directly from the relational model. SQL, the language used to define and query relational data, is also the common point of reference for discussing query capability.
As you watch, keep a running vocabulary list: table, row, column, schema, primary key, foreign key, constraint, join, normalization. Pay attention to why designers split data across multiple tables instead of storing everything in one large table, and notice how the videos illustrate relationships (one-to-one, one-to-many, many-to-many) and what a foreign key constraint prevents from happening.
An overview video from IBM Technology that introduces what a relational database is and how data is arranged in tables of rows and columns. Based on its title and description, it should cover the basic structure and terminology of the relational model and connect it to SQL and to real relational database products. It serves as the conceptual starting point before the key-focused videos.
It is a short, vendor-produced explainer from a major database provider that directly addresses the "What Is a Relational Database?", "Tables and Schema", and "Querying with SQL" subtopics in plain language suitable for a first exposure.
Part two of Lucid Software's entity relationship diagram tutorial, focused on primary keys, foreign keys, and bridge (junction) tables. The description indicates it moves into more advanced ERD concepts, so expect worked diagram examples showing how entities are linked and how many-to-many relationships are resolved with an intermediate table. It is the longest of the three videos and the most design-oriented.
Lucidchart's tutorial series is a widely used reference for database design, and this installment maps closely onto the "Primary Keys" and "Foreign Keys and Relationships" subtopics while showing the visual modeling that underlies good table and schema design.
A brief, focused explainer from CockroachDB on foreign key constraints. Per its title and description, it defines what a foreign key is, contrasts it with a primary key, and explains why the constraint is important for keeping related data consistent. Its short length makes it a useful review or reinforcement after the ERD tutorial.
It isolates the single idea students most often confuse — primary key versus foreign key — and frames it as a constraint, which ties the key vocabulary directly to the data integrity criterion used later in the module.
Together these videos build the vocabulary and structural understanding the module requires. The IBM overview and the Lucidchart tutorial supply the terms in MO1 — records, fields, tables, schema, primary keys, foreign keys — in the context where they are actually used, while the CockroachDB video sharpens the primary-versus-foreign-key distinction and introduces constraints. Because the relational model is the reference point for MO2 and MO3, seeing clearly how tables, fixed schemas, keys, and SQL queries work gives you a concrete basis for contrasting relational systems with NoSQL and hierarchical models on schema flexibility, query capability, scalability, and data integrity. That comparison, in turn, is what you will draw on when selecting and justifying a database type for an application scenario (MO4) or identifying the model likely used in a given industry (MO5).
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
NoSQL databases emerged as an alternative to the relational model for situations where rigid table structures, fixed schemas, and single-server scaling become limitations. Instead of organizing everything into rows and columns linked by keys, NoSQL systems store data in formats that more closely match how applications actually use it: documents, key-value pairs, wide columns, or graphs. The name is usually read as "not only SQL" rather than a rejection of SQL, because most organizations run both kinds of systems side by side.
In this course, NoSQL matters because it gives you a second point of comparison. Once you can describe how a relational database enforces structure and integrity, you can evaluate what a NoSQL system gains (flexible schema, horizontal scaling across many commodity servers, high write throughput) and what it gives up (standardized querying, multi-table joins, strict consistency guarantees). That trade-off analysis is the heart of choosing a database for a real application.
As you watch the videos below, keep a running comparison table in your notes. Look for: the four main data models and what kind of data each suits; what "schemaless" or "flexible schema" actually means in practice; the difference between scaling up and scaling out; and the specific workloads — large-scale web apps, real-time analytics, content and session storage, social graphs — where NoSQL tends to win. Equally important, note where the videos acknowledge limitations, because no single database type is correct for every scenario.
A longer overview from IBM Technology that introduces what a NoSQL database is and walks through the major categories of NoSQL systems and the scalability properties that make them suited to modern, distributed applications. Expect coverage of data model types, horizontal scaling, and typical application scenarios as suggested by the title and framing.
As the most comprehensive of the three videos, it gives you the broadest treatment of core data models, flexible schema design, and scalability — the central subtopics here — from a vendor-neutral enterprise technology channel.
A short lightboard explainer in which an IBM engineer lays out the top differences between SQL and NoSQL databases, drawn across categories such as structure, schema, scaling approach, and query style. The format is a direct, side-by-side comparison rather than a deep dive into any one system.
It is the clearest bridge between this topic and the relational material in the module, directly supporting the "when NoSQL outperforms relational systems" and trade-offs subtopics in a compact six minutes.
A concise, beginner-friendly explanation of how NoSQL databases work behind the scenes, including why they can be fast and highly scalable compared with traditional approaches. The description points to coverage of the mechanisms that enable scale, which is useful for understanding performance characteristics rather than just listing features.
With over a million views, this is a well-tested introductory explainer that makes the scalability and performance advantages understandable before you encounter the more technical vocabulary in the other two videos.
Together these videos reinforce MO2 and MO3 most directly: they define NoSQL as a structural category, present its core data models, and compare it against relational systems on schema flexibility, query capability, scalability, and data integrity. The SQL versus NoSQL comparison supplies the explicit criteria you will need for MO3, while the IBM overview and the "how it works" explainer supply the evidence behind those criteria. The application scenarios raised across all three — large-scale web platforms, real-time and high-volume workloads, content and session data — give you concrete cases to reason from when selecting a database type for a given situation (MO4) and when identifying which database type an industry such as e-commerce or social media is likely to rely on (MO5). The relational vocabulary of MO1 is assumed background here, so review it first if the comparisons feel unfamiliar.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Hierarchical databases organize information as a tree: a single root record branches into child records, and each child has exactly one parent. This structure was the dominant approach in early commercial database systems such as IBM's IMS, and it still shapes how we think about nested data today — think of file systems, organizational charts, or XML and JSON documents. Because relationships are built directly into the storage structure through parent-child links, navigating a hierarchical database means following those links from the root downward rather than writing a declarative query.
In this course, hierarchical databases matter for two reasons. First, they give you historical context: understanding what came before the relational model makes it much clearer why tables, keys, and SQL were such an important advance. Second, they sharpen your ability to compare models — hierarchical databases are fast and predictable for queries that follow the tree, but awkward or impossible for many-to-many relationships and for questions the designer did not anticipate.
As you watch, look for three things: how the tree structure and parent-child rule are defined, how data access and navigation differ from relational querying, and where each model's strengths and limitations show up. Note that the third video shifts from data models to B-trees, an internal tree structure used inside modern database engines — keep that distinction clear in your notes, since a tree-shaped index is not the same thing as a hierarchical data model.
A short survey of the major DBMS data models — hierarchical, network, relational, and object-oriented — presented with simple examples. The hierarchical segment should introduce the tree-based layout and parent-child relationships, then place that model alongside the alternatives that followed it. Expect definitions and comparisons rather than hands-on implementation.
Because it covers four models in one pass, it is an efficient way to see where hierarchical databases sit historically and structurally relative to the relational model you will study next.
A lecture-style walkthrough of the relational, network, and hierarchical data models, framed as question-and-answer practice. At fifteen minutes it has room to go deeper on how each model represents relationships, which should include the single-parent rule of hierarchies and the contrast with the network model's multiple parents. The Q-and-A framing means you will likely hear the kinds of exam questions asked about these models.
The longer, slower treatment reinforces the distinctions from the first video and gives you practice articulating the strengths and limitations of each model in your own words.
An animated explanation of B-trees, the balanced tree data structure widely used for indexing in databases and file systems. The video should show how a B-tree keeps data sorted and searchable, how nodes split as data grows, and why this keeps lookups fast on very large datasets. This is about internal storage and indexing, not about the hierarchical data model.
Spanning Tree is a well-regarded explainer channel, and this video builds your intuition for tree-based organization and navigation — useful background that also helps you avoid confusing a tree-shaped index with a hierarchical database model.
Together these videos support MO2 and MO3 most directly: the first two place the hierarchical model side by side with the relational and network models so you can distinguish them by structural organization and by how they express data relationships, and then compare them on query capability, flexibility, and data integrity. The vocabulary introduced across both lectures — records, parent and child segments, schema, keys — reinforces MO1. Understanding why hierarchical access paths are rigid and why relational querying is more flexible gives you the reasoning you need for MO4 and MO5, where you must justify a database choice for a given application or industry. The B-tree video adds depth on tree-based navigation and performance at scale, which strengthens the scalability dimension of MO3.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Up to this point you have met relational, NoSQL, and hierarchical databases one at a time. This topic places them side by side so you can see how their structures, schemas, query languages, scaling behavior, and consistency guarantees differ — and, more importantly, why those differences matter when someone has to pick one for a real system.
There is no "best" database. A rigid schema that feels restrictive in one project is exactly what protects financial records in another; a flexible document store that speeds up a startup's prototype can quietly allow inconsistent data later. The goal here is to build a mental checklist of selection criteria: What does the data look like? How will it be queried? How much will it grow? How costly is an inconsistent read?
As you watch the two videos below, keep a comparison table in your notes with columns for structure, schema flexibility, query power, scalability, and integrity. Note the vocabulary each speaker uses (normalization, joins, ACID, horizontal versus vertical scaling, eventual consistency) and jot down the example use cases they mention — you will be asked to justify database choices for similar scenarios later in this module.
An IBM Technology explainer that contrasts relational databases with non-relational (NoSQL) alternatives. Based on its title and description, it is likely to walk through how tables, rows, and columns with predefined schemas compare to document, key-value, and other non-relational structures, and to touch on where each approach performs well in terms of flexibility, scale, and the kind of querying it supports.
IBM Technology produces concise, vendor-neutral conceptual overviews, and this one maps directly onto the structural differences, schema flexibility, and query power subtopics by addressing the core relational-versus-NoSQL contrast at the heart of this comparison.
A ByteByteGo video framed around the practical question of how to choose a database for a given system. From its title and the channel's system design focus, expect a tour of major database families and the criteria engineers weigh — data shape, query patterns, scale and performance demands, and consistency requirements — with example scenarios that match categories to workloads.
ByteByteGo is widely used for system design preparation and specializes in exactly this decision-making framing, making it a strong fit for the scalability trade-offs, ideal use cases, and key selection criteria subtopics.
Together these videos reinforce the comparison and selection outcomes of this module. The IBM Technology video supports MO2 and MO3 by clarifying how relational and non-relational models organize data differently and how that drives schema, query, and scaling trade-offs, while reinforcing the vocabulary introduced in MO1. The ByteByteGo video extends this toward MO4 and MO5 by modeling how practitioners weigh criteria and match database types to concrete application and industry scenarios. Watched in sequence, they move you from understanding the differences to being able to justify a choice.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Almost every digital service you used today was backed by a database. When you browse a product catalog, check a bank balance, refill a prescription, submit an assignment, or scroll a social feed, software is reading from and writing to a data store that someone designed on purpose. This topic looks at that connection between database theory and the systems people actually rely on: e-commerce and retail, healthcare records, banking and financial services, social media and content platforms, education and learning management systems, government and public services, and transportation and logistics.
The reason this matters in COP4708 is that different industries place very different demands on their data. A bank cannot tolerate a transfer that debits one account without crediting another, so it leans on strict transactional guarantees. A social platform serves enormous volumes of reads and can often accept slightly stale data in exchange for speed and scale. A hospital must keep records accurate, auditable, and available. Those pressures — correctness, scale, flexibility, and reporting needs — are what push designers toward relational, NoSQL, or other models.
The three videos below come from ByteByteGo, a channel focused on system design. Rather than touring industries one by one, they give you the vocabulary that explains why industries choose what they choose: transactional guarantees, core architectural building blocks, and the pipelines that move data from operational systems into analytics. As you watch, keep asking yourself which industry from the subtopic list would care most about each idea, and why.
This video explains the ACID properties — atomicity, consistency, isolation, and durability — that define how reliable database transactions behave, and it works through examples to make each property concrete. Expect scenarios along the lines of money transfers or order processing, where a partially completed operation would leave the data in a broken state. It should also make clear why these guarantees are a feature of transactional database engines rather than something application code can easily fake.
ACID is the single clearest explanation for why banking, financial services, healthcare records, and e-commerce checkout systems overwhelmingly rely on transactional relational databases, which makes this a direct fit for the industry-matching subtopics.
This video surveys eight widely used system design concepts, the kind of building blocks that appear in large-scale production architectures. Based on the channel's focus, expect coverage of ideas such as caching, replication, partitioning or sharding, load balancing, and consistency trade-offs, presented at a high level with animated diagrams. It is a vocabulary-building overview rather than a deep dive into any one mechanism.
It frames the trade-offs — scale, availability, consistency — that separate a social media or content platform's data layer from a bank's, giving you the language to justify database choices across different application domains.
This video introduces data pipelines: how data is collected from operational sources, moved, transformed, and loaded into systems used for reporting, analytics, or machine learning. It should cover the typical stages of a pipeline and explain why organizations build them instead of querying production databases directly. The emphasis is on the role pipelines play in a larger data ecosystem.
Retail, logistics, government, and learning management systems all depend on moving operational data into analytical stores, so this video extends the topic beyond the single application database to how real organizations actually use their data.
Together these videos connect database concepts to working systems. The ACID video supports MO3 and MO5 by showing what data integrity really guarantees and why integrity-critical industries such as banking and healthcare depend on it. The system design overview supports MO2, MO3, and MO4 by surfacing the scalability, consistency, and flexibility trade-offs you use as selection criteria when matching a database model to a scenario. The data pipeline video broadens the picture for MO4 and MO5, showing that real applications in retail, logistics, and public services often combine transactional and analytical stores. The module's vocabulary outcome (MO1) is reinforced indirectly, since all three videos use terms like transaction, schema, replication, and query in realistic context.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.