Overview
Database courses move quickly from entity-relationship diagrams to functional dependencies, normal forms and SQL, and the connections between them are easy to miss. We teach the thread that links them: an ER model captures what the data means, the relational schema turns it into tables and keys, normalization removes redundancy that causes update anomalies, and SQL queries depend on all of those decisions.
Researchers face the same design questions in a different setting. A survey spread across spreadsheets, a lab tracking samples and assays, or a digital humanities project linking people, places and documents often benefits from a small relational database. We review or design schemas for these projects, write the SQL that creates them and document the model so others can use it.
For coursework, we explain concepts, work through different example scenarios and review the schemas and queries you design. For research and professional databases, we can produce the schema, migration scripts and documentation for you.
Who it’s for and the problems it solves
This is for you if you are…
- Undergraduates in introductory and advanced database courses
- Information systems and business students modeling data for projects
- Researchers organizing survey, lab, archival or fieldwork data into a relational database
- Professionals learning SQL for analytics or reporting roles
- Small teams building an application that needs a clean schema from the start
Common problems we help with
- You cannot tell whether something should be an entity, an attribute or a relationship
- Cardinality and participation constraints (1:N, M:N, optional versus mandatory) keep confusing you
- Finding functional dependencies and candidate keys for normalization exercises feels like guesswork
- Your queries return duplicate rows or miss records, especially with joins and NULLs
- A research dataset lives in many spreadsheets with inconsistent IDs and repeated information
What’s included — and what isn’t
Included
- Conceptual modeling: entities, attributes, relationships, cardinality, participation, weak entities and ISA hierarchies
- ER notation guidance: Chen, crow's foot and UML class diagram notation, and how to convert between them
- Mapping ER models to relational schemas, including M:N junction tables and handling of multivalued attributes
- Keys and constraints: primary, candidate, foreign and surrogate keys, UNIQUE, CHECK and referential actions
- Normalization: functional dependencies, closure, 1NF, 2NF, 3NF and BCNF, decomposition, lossless joins and dependency preservation
- Deliberate denormalization for reporting or performance, with its trade-offs explained
- SQL: DDL and DML, joins (inner, outer, self), aggregation, subqueries, CTEs, window functions and views
- Relational algebra and its connection to SQL, as covered in many university courses
- Transactions and ACID properties, isolation levels and common concurrency anomalies
- Indexing and query performance: B-tree indexes, composite index column order, reading EXPLAIN output
- Schema review or design for research and professional databases, with a data dictionary
Not included
- Completing graded database assignments, ER diagrams or SQL exercises for submission
- Administering production database servers, backups or security hardening
- Designing databases that store personal or health data without the owner confirming ethics approval and data protection arrangements
What you receive
- Worked examples
- ER models and normalization walkthroughs on scenarios different from your assignment, showing each decision and why.
- Schema review
- Comments on your ER diagram or table definitions: missing keys, redundancy, anomalies, naming and constraint issues, with explanations.
- Schema and DDL scripts
- For research and professional clients: an ER diagram and SQL scripts to create tables, keys, constraints and indexes in your chosen database system.
- Data dictionary
- A table-by-table description of every column, its type, allowed values and meaning, which also supports data management plans and archiving.
- Query review
- Line-by-line comments on queries you wrote, with test data that shows where results differ from what you expect.
How it works
Understand the domain
We start from the real-world situation: what things are tracked, how they relate and which questions the database must answer.
Model conceptually
We sketch or review the ER model together, testing it against example records and edge cases.
Map and normalize
The model becomes tables and keys, and we check functional dependencies to reach at least third normal form unless there is a reason not to.
Query and test
We write or review queries against small test data, then look at indexes for the most frequent queries.
Document
You receive notes, reviewed diagrams or, for research builds, scripts and a data dictionary.
Design methods and database tools
- Functional dependency analysis
- Identifying dependencies from business rules, computing attribute closures and deriving candidate keys before choosing a decomposition.
- Normal forms
- Checking for partial dependencies (2NF), transitive dependencies (3NF) and determinants that are not superkeys (BCNF), with examples of insertion, update and deletion anomalies.
- Modeling tools
- draw.io, Lucidchart, dbdiagram.io, MySQL Workbench, pgModeler or the diagram tool your course requires.
- Database systems
- PostgreSQL, MySQL and MariaDB, SQLite for single-user research projects, SQL Server and Oracle where your institution uses them.
- Query plans
- Reading EXPLAIN or EXPLAIN ANALYZE output to see scans, joins and index use, then testing whether an index actually helps.
- Non-relational options
- Discussing when a document store, graph database or plain files suit the data better than a relational schema.
Normalization in plain terms
Normalization is a way of making each fact live in one place. If a course's instructor name is stored in every enrollment row, changing it means updating many rows, and missing one leaves the data contradictory. Moving that fact to a courses table removes the problem. The normal forms are formal tests for this kind of redundancy.
Students often memorize the definitions without the underlying skill, which is spotting functional dependencies in a messy table. We practice that skill on realistic examples until the decomposition follows naturally.
Common SQL mistakes we help you catch
Many wrong query results come from a small set of misunderstandings. We test each with tiny tables so you can see the effect directly.
- Comparing with = NULL instead of IS NULL, and NOT IN with a subquery that contains NULLs
- Joining two one-to-many tables at once and double counting in SUM or COUNT
- Filtering an outer join in WHERE instead of ON, which silently turns it into an inner join
- Selecting non-aggregated columns with GROUP BY, which some systems allow and others reject
- Assuming row order without ORDER BY
Databases for research projects
A small, well-designed database can replace a folder of spreadsheets and make research data easier to validate, query and archive. We pay attention to stable identifiers, controlled vocabularies, date and unit conventions, and a data dictionary that can be deposited with the data. If your project collects personal data, the design should follow your ethics approval and data protection plan, and we can align it with a data management plan.
What the work can look like
Illustrative example — fictional data
Sample normalization walkthrough on an invented lab table
A lab tracked samples in one spreadsheet with columns SampleID, CollectedOn, SiteCode, SiteName, SiteLatitude, AssayType, AssayDate and TechnicianEmail. The table and decisions are invented for illustration.
Dependencies found
SiteCode determines SiteName and SiteLatitude; SampleID determines CollectedOn and SiteCode; each sample can have several assays, each with its own date and technician. Site details therefore depend on SiteCode, not on the sample, which is a transitive dependency.
Decomposition
Three tables: Site(SiteCode PK, SiteName, Latitude), Sample(SampleID PK, CollectedOn, SiteCode FK), Assay(AssayID PK, SampleID FK, AssayType, AssayDate, TechnicianID FK), plus Technician(TechnicianID PK, Email). Each fact now appears once.
Practical additions
A CHECK constraint keeps latitude between −90 and 90, a controlled list defines AssayType, and an index on Assay(SampleID) supports the most common query: all assays for a sample.
Illustrative example with an invented dataset. Real designs follow your data, rules and database system.
What you’ll need to provide
- The scenario, assignment topic or research data description
- Any existing ER diagrams, table definitions, spreadsheets or sample data (anonymized)
- The notation and database system your course or project uses (for example PostgreSQL, MySQL, SQLite, SQL Server, Oracle)
- The main questions or reports the database must support
You don’t need everything ready to ask for a quote — tell us what you have and we’ll say what’s missing.
What affects price and turnaround
Price depends on
- Tutoring sessions, written review or a full schema design
- Number of entities and relationships, and the complexity of the business rules
- Volume and condition of existing data to be migrated
- Whether query optimization, a data dictionary or migration scripts are required
Turnaround depends on
- Clarity of the requirements and how quickly domain questions can be answered
- Amount of data cleaning needed before a schema can be tested
- Your course deadlines and availability for sessions
Every project is quoted individually. How we price our work.
Questions people ask before starting
Can you draw the ER diagram for my assignment?
No. We teach ER modeling on different scenarios, explain the notation your course uses and review the diagram you draw, pointing out issues and why they matter. The assessed diagram and schema stay your work.
Do I always need to normalize to BCNF?
Not always. Third normal form is the usual practical target, and BCNF is stricter; in rare cases a BCNF decomposition cannot preserve all dependencies. Analytical databases are often deliberately denormalized for query speed. We explain the trade-off so you can justify your choice.
Which database system should I use for a research project?
For a single researcher or small team, SQLite is often enough and stores everything in one file. PostgreSQL suits multi-user projects, spatial data (with PostGIS) or larger volumes. Your institution may also provide managed databases. We recommend based on users, size, hosting and data protection requirements.
Can you help me move data from Excel into a database?
Yes. We design the target schema, identify inconsistencies such as duplicate IDs or mixed date formats, and write import scripts in SQL, Python or R. You review decisions about how to resolve conflicting records, since those depend on knowledge of the data.
Do you cover NoSQL databases?
We explain when document, key-value or graph databases are a better fit and cover their data modeling basics, for example embedding versus referencing in MongoDB. Most of our database design work is relational.