TEC-DATA86-01 · Lesson 3 · 28 clock hours · practice
Trade Math for Database Administration
Objective. Students will correctly convert between binary, octal, and hexadecimal numbering systems and perform storage-capacity, throughput, and basic descriptive-statistics calculations used in database sizing, performance analysis, and capacity planning.
⚠ Pending professional review
This lesson, its worked examples and its practice questions has not yet been verified by an industry-certified professional or by a certification or approval body. It is a study draft and may contain errors. Do not use it as instructions for work on a job site or on live equipment. Always follow your instructor, your supervising professional, and current official references and regulations.
VoTechWorks program approval and accreditation are still in progress. Credentials are issued only by the certifying bodies named in each program, after their own exams.
Why Database Administrators Need Trade Math
A DBA who cannot size a database accurately may under-provision storage, causing outages, or over-provision it, wasting budget. The math in this lesson appears directly in day-to-day work: estimating how much disk space a new application will consume, interpreting performance data, and presenting findings to management. It also maps to exam objectives for Oracle DBA CA (performance tuning), Microsoft DP-300 (Azure SQL resource planning), DAMA CDMP (data quality metrics), and PostgreSQL CE (storage configuration).
---
Number Systems Used in Database Work
Computers store all data in binary (base 2), but DBAs also encounter octal (base 8) and hexadecimal (base 16) regularly — in IP addressing, memory dump analysis, and permission flags.
Binary (Base 2)
Digits are 0 and 1. Each position is a power of 2. To convert binary to decimal, multiply each bit by its positional power and sum:
`1011₂ = (1×8) + (0×4) + (1×2) + (1×1) = 11₁₀`
To convert decimal to binary, repeatedly divide by 2 and record remainders from bottom to top.
Hexadecimal (Base 16)
Digits are 0–9 and A–F (A=10 through F=15). Each hex digit represents exactly four binary bits (a nibble), making hex a compact shorthand for binary. IPv6 addresses, color codes, and memory addresses all use hex.
Conversion shortcut: group binary digits in fours from the right, convert each group to one hex digit.
`10110111₂ → 1011 0111 → B7₁₆`
Octal (Base 8)
Digits are 0–7. Linux/Unix file permissions (e.g., `chmod 755`) use octal. Group binary in threes from the right:
`101111₂ → 101 111 → 57₈`
---
Storage Units: SI vs. IEC Prefixes
One of the most common sources of sizing errors is confusing SI (decimal) prefixes with IEC (binary) prefixes. The IEEE and NIST both recognize the IEC standard (IEC 80000-13).
| IEC Name | IEC Symbol | Value | SI Name | SI Symbol | Value |
|---|---|---|---|---|---|
| Kibibyte | KiB | 2¹⁰ = 1,024 B | Kilobyte | KB | 10³ = 1,000 B |
| Mebibyte | MiB | 2²⁰ = 1,048,576 B | Megabyte | MB | 10⁶ B |
| Gibibyte | GiB | 2³⁰ ≈ 1.074 × 10⁹ B | Gigabyte | GB | 10⁹ B |
| Tebibyte | TiB | 2⁴⁰ ≈ 1.099 × 10¹² B | Terabyte | TB | 10¹² B |
Storage vendors typically advertise disk capacity in SI gigabytes, while operating systems often report in IEC gibibytes. This gap explains why a "500 GB" hard drive appears as roughly 465 GiB in Windows or Linux. Always clarify which convention a specification uses before sizing a database.
---
Database Sizing Formula
A standard DBA sizing estimate follows these steps:
1. Raw data size = Row count × Average row width (bytes)
2. Table overhead factor: Add roughly 20–30% for index space, transaction logs, and database overhead (use whatever factor your DBA guide or vendor documentation specifies for your platform).
3. Replication factor: Multiply by the number of copies (e.g., ×3 for a three-replica cluster).
4. Growth projection: Multiply the current-year size by `(1 + annual growth rate)^years` using compound growth.
5. Cost estimate: Multiply projected storage in GB by the cost per GB.
Always document your assumptions. Presenting assumptions alongside numbers is a core data-management professional practice emphasized in the DAMA CDMP body of knowledge.
---
Throughput Calculations
Throughput is the rate at which data moves. A common unit is MB/s (megabytes per second). To estimate how long a data load will take:
`Time (seconds) = File size (MB) ÷ Throughput (MB/s)`
For network bandwidth given in Mbps (megabits per second), convert to MB/s by dividing by 8:
`1 Gbps = 1,000 Mbps = 125 MB/s`
---
Basic Descriptive Statistics for Performance Analysis
When monitoring query response times, DBAs calculate three key statistics:
- Mean (average): Sum of all values ÷ count of values. Sensitive to outliers.
- Median: The middle value when data are sorted. More robust to outliers than the mean.
- Standard deviation (σ): Measures spread around the mean. A high standard deviation for query times signals inconsistent performance — a red flag during incident investigations.
In a spreadsheet, use `=AVERAGE()`, `=MEDIAN()`, and `=STDEV()` (sample standard deviation) or `=STDEVP()` (population). For a performance dashboard submitted in an incident report, label every column clearly and include units (e.g., milliseconds).
---
Safety in the Data Center Lab
Although database administration is primarily software work, lab sessions take place around server hardware. Follow these safe practices:
- Electrical safety: Never open powered server chassis. Data centers use high-density power; treat all rack-mounted equipment as energized unless confirmed otherwise by a qualified technician using lockout/tagout (LOTO) procedures.
- Ergonomics: Position monitors at eye level and keyboards at elbow height to prevent repetitive-strain injury during extended calculation and spreadsheet sessions.
- Data safety: Never enter real personal or financial data into practice databases. Use synthetic or anonymized data sets only.
- File hygiene: Save spreadsheet work frequently and back up to the designated network share before submitting — data loss during a lab session is not an acceptable excuse for an incomplete deliverable in a professional environment.
Key terms8
Binary (base 2)A numbering system using only digits 0 and 1, where each digit position represents a power of 2; the native language of all digital computer hardware.
Hexadecimal (base 16)A numbering system using digits 0–9 and letters A–F, where each digit represents four binary bits; widely used in memory addresses, IPv6, and data dumps.
IEC prefix (binary prefix)A standardized prefix (kibibyte, mebibyte, gibibyte, etc.) defined by the IEC in which each step is a power of 2 (1,024); distinguishes binary-based sizes from decimal SI prefixes.
SI prefix (decimal prefix)A metric prefix (kilobyte, megabyte, gigabyte, etc.) in which each step is a power of 10 (1,000); used by storage manufacturers when marketing drive capacities.
ThroughputThe rate at which data is transferred or processed, commonly measured in megabytes per second (MB/s) or megabits per second (Mbps); a key metric in database load and network planning.
Replication factorThe number of identical copies of data maintained across servers in a cluster; multiplies raw storage requirements and must be accounted for in capacity planning.
Standard deviationA statistical measure of how spread out values are around their mean; a high standard deviation in query response times indicates inconsistent database performance.
Compound growthA method of projecting a value forward using the formula: Future value = Present value × (1 + rate)^years; used in database capacity planning to estimate storage needs over time.
Worked examples4
1. Convert the decimal number 219 to binary and then to hexadecimal.
- Divide 219 by 2 repeatedly, recording remainders: 219÷2=109 R1, 109÷2=54 R1, 54÷2=27 R0, 27÷2=13 R1, 13÷2=6 R1, 6÷2=3 R0, 3÷2=1 R1, 1÷2=0 R1.
- Read remainders from bottom to top: binary = 11011011₂.
- Group the binary digits into nibbles (groups of four) from the right: 1101 1011.
- Convert each nibble: 1101 = 13 = D, 1011 = 11 = B.
- Result in hexadecimal: DB₁₆.
Answer: 219₁₀ = 11011011₂ = DB₁₆
2. A database table will hold 8,000,000 rows. Each row averages 512 bytes. The design requires a 25% overhead factor for indexes and logs, and a replication factor of 3. Calculate the total raw storage needed in gibibytes (GiB).
- Calculate raw table data: 8,000,000 rows × 512 bytes = 4,096,000,000 bytes.
- Apply 25% overhead factor: 4,096,000,000 × 1.25 = 5,120,000,000 bytes.
- Apply replication factor of 3: 5,120,000,000 × 3 = 15,360,000,000 bytes.
- Convert bytes to GiB using 1 GiB = 2³⁰ = 1,073,741,824 bytes: 15,360,000,000 ÷ 1,073,741,824 ≈ 14.31 GiB.
Answer: Approximately 14.31 GiB of raw storage is required.
3. A database currently occupies 200 GiB. The data grows at 15% per year. What is the projected size after 3 years? If storage costs $0.10 per GB (SI), what is the estimated three-year cost for just the Year 3 capacity? Use 1 GiB ≈ 1.074 GB for conversion.
- Apply compound growth: 200 GiB × (1 + 0.15)³ = 200 × 1.520875 ≈ 304.18 GiB.
- Convert to GB (SI): 304.18 GiB × 1.074 GB/GiB ≈ 326.69 GB.
- Calculate storage cost at $0.10 per GB: 326.69 × $0.10 ≈ $32.67.
- This is the cost for Year 3 capacity. Present this figure alongside your assumptions when briefing management.
Answer: Projected Year 3 size ≈ 304.18 GiB (≈ 326.69 GB); estimated Year 3 capacity cost ≈ $32.67 at $0.10/GB.
4. Five query response times (in milliseconds) were recorded: 42, 38, 95, 41, 44. Calculate the mean and identify whether the median or mean is more representative of typical performance.
- Sort values: 38, 41, 42, 44, 95.
- Calculate mean: (38 + 41 + 42 + 44 + 95) ÷ 5 = 260 ÷ 5 = 52 ms.
- Find median (middle value of 5 sorted values): 42 ms.
- The value 95 ms is an outlier that pulls the mean up to 52 ms, while four of the five queries completed in 38–44 ms.
- Conclusion: The median (42 ms) better represents typical performance; the outlier should be investigated separately.
Answer: Mean = 52 ms; Median = 42 ms. The median is more representative because one outlier (95 ms) skews the mean upward.
The math in this lesson2
Learners use powers of 2 and 1024 to convert between storage units.
8.EE.4N-Q.1
In class: Complete a structured drill set covering number-base conversions (binary ↔ decimal ↔ hex), byte-unit arithmetic (kilobytes through terabytes, including IEC vs. SI prefixes), and IP-subnet calculations; check answers with a provided key and correct errors in a second-attempt column. · Work through a database-sizing case study: given a fictional application's row count, average row width in bytes, expected annual growth rate, and a replication factor, calculate raw storage requirements, usable capacity after overhead, and projected three-year storage cost at a stated price-per-gigabyte—replicating the kind of sizing estimate a DBA presents to management. · Use a spreadsheet (Microsoft Excel or LibreOffice Calc) to build a simple performance-baseline dashboard that calculates mean, median, and standard deviation for a provided set of query response-time samples, then formats the results as a table and a bar chart suitable for an incident report — a skill directly relevant to Oracle DBA CA performance-tuning exam objectives and DAMA CDMP data-quality metrics.
Materials: Scientific calculator, Microsoft Excel or LibreOffice Calc (installed on lab workstations), drill-set handout, database-sizing case study worksheet, provided query-response-time data CSV file, IEEE/NIST unit-prefix reference card
Check: Scored math quiz covering number-base conversions and byte arithmetic — 80% or higher to pass; completed spreadsheet dashboard submitted and checked against an answer key for correct formulas, accurate statistics, and readable chart — all three sections must be correct or corrected within the class period.
Practice check8
Answer each question, then check it. Nothing is recorded; this is your own practice.
Record this lesson on my transcript. Sign in with your key and enrollment email to record lessons (enroll free if you have no key). This page stays open to read and practise.