A cardinalidade de uma união entre duas tabelas é a relação numérica entre as linhas de uma tabela e as linhas da outra. As cardinalidades comuns incluem um-para-um, um-para-muitos e muitos-para-muitos.

Por exemplo, considere uma base de dados de registos de saúde electrónicos. Tal banco de dados poderia conter tabelas como as seguintes:

• A doctor tabela com informações sobre médicos.
• A patient tabela para médicos em tratamento.
• An encounter tabela com uma entrada para cada visita ao hospital.

Existem relações naturais entre estas entidades, como um encontro envolvendo muitos médicos. Existe uma relação de muitos para muitos entre registos em doctor e registos em patient porque os médicos têm muitos pacientes e os pacientes podem ver muitos médicos. Existe uma relação de um para muitos entre os registros em patient e os registros em encounter porque os pacientes podem ter muitos encontros e cada encontro envolve apenas um paciente.

Uma relação “um para um” é usada principalmente para dividir uma tabela em duas, a fim de fornecer informações de forma concisa e torná-la mais compreensível. No exemplo do hospital, tal relação poderia ser usada para manter separadas as informações profissionais exclusivas dos médicos dos detalhes administrativos.

Na modelagem de dados, coleções de elementos de dados são agrupadas em “tabelas de dados” que contêm grupos de nomes de campos de dados chamados “atributos de banco de dados”. As tabelas são ligadas por “campos-chave”. Uma “chave primária” atribui um campo à sua “tabela de ordem especial”. Por exemplo, o campo “Doutor Sobrenome” pode ser atribuído como chave primária da tabela Doutor com todas as pessoas com o mesmo sobrenome organizado alfabeticamente de acordo com as três primeiras letras do seu primeiro nome. Uma tabela também pode ter uma chave estrangeira que indica que o campo está ligado à chave primária de outra tabela.

Um modelo de dados complexo pode envolver centenas de tabelas relacionadas. O cientista da computação Edgar F. Codd criou um método sistemático para decompor e organizar bases de dados relacionais. Os passos do Codd para organizar tabelas de bancos de dados e suas chaves são chamados de normalização de bancos de dados, o que evita certos erros ocultos no projeto de bancos de dados (excluir anomalias ou atualizar anomalias). Na vida real o processo de normalização de bases de dados acaba por dividir as tabelas num número maior de tabelas menores.

No mundo real, a modelação de dados é crítica porque à medida que os dados crescem volumosos, as tabelas ligadas por chaves devem ser usadas para acelerar a recuperação programada de dados. Se um modelo de dados for mal trabalhado, mesmo um sistema de aplicações informáticas com apenas um milhão de registros dará aos usuários finais atrasos inaceitáveis no tempo de resposta. Por esta razão, a modelagem de dados é uma pedra-chave nas habilidades necessárias por um desenvolvedor de software moderno.