CompTIA Tech+ (FC0-U71): Data and Database Fundamentals — Value of Data, Database Structures and Backups

Data is raw facts — individual readings, clicks, sales or survey answers — and information is data that has been processed, organized and given context so it means something and can support a decision. Each swipe of a membership card at a gym's entrance is data; a chart of the busiest hours that the manager uses to plan staff rotas is information. The same raw facts can produce many pieces of information, depending on how they are summarized and for whom.

Treating data and information as an asset means the organization recognizes that its data has value, just like equipment, property or cash, so it records what the data is worth, spends to protect it and plans how to use it. A member database, a product design archive or a hospital's staff records cost money to collect, earns money when used well and causes real harm when lost or stolen. That is why businesses secure, back up and govern data rather than leaving it scattered on personal devices.

Critical vs non-critical data

Critical data is data the organization cannot operate without and cannot easily re-create: accounting ledgers, payroll, signed contracts, a hospital's shift rota. Non-critical data is useful but either not needed to keep running or easy to get back: marketing brochures, old event photos, cached copies of web pages, software installers that can be downloaded again. The split sets priorities. When time, storage or budget is limited, critical data is protected, backed up and restored first.

Data monetization: earning value from data

Data monetization is earning revenue from data. It comes in two forms:

• Direct monetization — selling or licensing data (usually anonymized and combined) to other organizations, such as a navigation app licensing anonymized, aggregated traffic-speed data to city planners.
• Indirect monetization — using the data internally to earn more: recommending products, targeting offers, setting prices or cutting waste. The data never leaves the company.

Monetization is about revenue, so it is different from activities that only protect or store data: those look after the asset but create no revenue by themselves. Valuing and protecting data is the asset view; turning it into money is monetization. Selling data also brings privacy duties: personal data is normally anonymized and aggregated, and laws and the organization's own privacy policy limit what may be shared.

Data becomes valuable through a chain of steps: it is captured, analyzed, checked for correlations and finally reported so people can make data-driven decisions.

Correlation is not causation

A correlation shows that two things change together; it does not prove that one causes the other. Umbrella sales and minor traffic accidents both rise on the same days because both follow heavy rain — banning umbrella sales would not make the roads safer. A hidden third factor that drives both sets of data is called a confounding factor, and gathering more of the same data does not remove it, because the mistake is in the conclusion, not in the amount of data. The reliable way to check a cause is a controlled comparison: make the change in one group and leave a matching group unchanged, so the only real difference between them is the change itself. Any comparison without a matched, unchanged group mixes the effect of the change with everything else that differs or happened at the same time.

Big Data

Big Data describes data sets so large, fast-arriving or varied that traditional tools, such as a single spreadsheet or an ordinary database, cannot handle them well. It is defined by what the data is like rather than by one size figure or by the product that holds it, and it is usually described by its characteristics, often called the Vs:

• Volume — the sheer amount of data.
• Velocity — how fast it arrives, such as sensor readings every second.
• Variety — the range of types and formats, such as numbers, images and free text together.
• Veracity — how accurate and trustworthy it is.

Meaningful reporting: turning data into a decision

A meaningful report is one that is relevant to the reader's decision and summarized so they can act on it at a glance. A raw export of every transaction holds the right data, but the reader has to do the analysis; technical details such as internal record IDs or server names are real data yet irrelevant to a business question. Good reports pick the right measure, the right time span and the right format.

Match the format to the question being asked: a trend needs a time axis, so anything that shows a single moment cannot reveal whether a figure is rising or falling.

A database is an organized collection of data stored so it can be added to, searched, updated and reported on efficiently, usually by many people and programs at once. The basic database uses named in the objectives are:

The near-twins: import brings data in, while export sends it out to a file. A query finds the data; a report presents it (a report is often built on a query's results). Queries are commonly written in SQL, the query language covered in the software development objectives.

A database stores data as records (one entry per item, such as one customer) on non-volatile storage, and offers characteristics that a simple file does not:

• Data persistence — saved data stays stored after the program closes, the computer restarts or the power fails. Shift changes saved before a server restart are still there afterwards.
• Multiple concurrent users — many people can read and change data at the same moment while the database keeps their changes from conflicting, so two receptionists booking the last place in a fitness class at the same moment cannot both get it.
• Scalability — the ability to grow to handle more data and more users.
• Speed — indexes and query engines find matching records quickly, even among millions.
• Variety of data — the range of data types a database can hold: text, numbers, dates, images, documents.
• Data availability — data is accessible to authorized users whenever they need it.

Flat file vs database

A flat file stores data as plain rows in a single file — a CSV, a text file or a single spreadsheet. It is simple and portable: any text editor or spreadsheet program can open a CSV, which makes it a good way to hand simple data to someone who has no database software. Its limits show as data and users grow: simultaneous edits can overwrite each other (even when the file sits in a shared cloud folder), there are no enforced relationships between tables, and searching large files is slow. A bigger spreadsheet is still a flat file.

A local database runs on hardware the organization owns — one PC or an office server — so it must buy, secure, power and maintain that hardware, and remote staff can reach it only if the business exposes it safely over the network. A cloud database is hosted and maintained by a provider and reached over the internet, so the organization runs no hardware of its own and authorized staff can connect wherever they have internet access; the trade-offs are an ongoing fee and a dependence on internet access.

Online access reads and writes the shared database live, which needs a working connection. Offline access stores data locally on the device while there is no connection, then synchronizes with the shared database once the device is online again — the pattern for an inspection app used in basements or rural sites with no signal. The deciding detail is where the data must end up: if it must reach the shared database eventually but the device is often disconnected, offline access with synchronization is the fit, because anything that depends on a live connection stops working without one.

Data is classified by how much organization it carries:

"Relational" is not one of these three: it describes a database design (tables linked by keys), not the shape of the data itself.

A relational database stores data in tables that are linked to each other through key fields, and enforces a fixed structure. Its vocabulary:

• Schema — the blueprint of the database: which tables exist, which fields each has, their data types, constraints and how tables relate. It holds no data itself.
• Table — a set of records about one kind of thing, such as Employees or Shifts.
• Row / record — one complete entry, such as one employee's ID, name and department.
• Field / column — one attribute stored for every record, such as Name.

Primary keys, foreign keys and constraints

A primary key is the field that uniquely identifies each record in its own table. A good one is unique, always present and never changes — an ID number the system assigns once is better than personal details, which can repeat, change or be missing.

A foreign key is a field in one table that refers to the primary key of another table, linking the two. MemberID is the primary key of a gym's Members table; the same field in its Bookings table is a foreign key, and many bookings can share one value.

Constraints are rules the database enforces on data:

A relational database is the right fit when every record must have the same required fields and links between tables must be enforced — a hospital's staff records and the shifts assigned to them, for example. A spreadsheet can limit what is typed into a cell, but it does not enforce referential integrity: it will not stop someone deleting a row that other rows still refer to, and pasted data can slip past its checks.

Non-relational (often called NoSQL) databases drop the fixed table schema to gain flexibility or raw speed. The two types named in the objectives:

The deciding question is how the data will be looked up. If it is only ever fetched by one ID, key/value is the simplest and fastest fit. If records vary in shape and people must search by details inside them, a document database fits; a relational design would need a schema change for every new kind of detail. A relational database would also work for a simple lookup, but its tables and relationships add structure that a key lookup never uses.

A backup is a separate copy of data kept so it can be restored after loss, corruption, theft or ransomware. The two kinds in the objectives differ in what comes back:

Anything that copies only files and folders, however it is done, cannot bring back the operating system or installed programs; that needs a system image.

Restoring data is the reason backups exist, so restores must be tested on a schedule: restore a sample and check it opens. A job that reports success proves only that the copy ran, not that the data can be read back; the only proof is a test restore.

Where a backup is kept decides which disasters it survives. Stored locally means on media at the same site:

Two location rules settle most scenarios. First, a backup that stays in the same building is lost with it in a fire, flood or theft, so keep at least one copy off-site, for example in cloud storage. Second, a drive that is always connected can be encrypted by the same ransomware as the computer; keep a copy out of its reach. The two remedies differ in who has to act: rotating drives keeps one copy unplugged, but only works if someone is on site to swap and disconnect the drives on schedule; versioned cloud storage keeps earlier versions of each file automatically, so files can be restored from before an infection with no one handling media. Combine the two choices: the type decides what comes back (files or the whole system), and the location decides what disasters it survives.