Entendimento do Banco de dados de Blocos de Construção no SQL Server

Como Este Blog 3

Adicionado por Pedro Ávila de novembro de 21, 2012

Cada casa tem uma cozinha, pelo menos, um banheiro e um quarto, a porta da frente, um sistema de encanamento, e outras coisas. Essas coisas podem ser organizadas de maneiras diferentes e em números diferentes para produzir casas diferentes. Assim é com bancos de dados. Há certas coisas que todos os bancos de dados têm em comum. Neste post, apresentarei os blocos de construção que compõem todos os bancos de dados e mostrarei como eles são montados. Também discutirei três regras que precisam ser seguidas ao usar os blocos de construção.

o material apresentado neste post deve ser de valor para qualquer pessoa que tenha qualquer tipo de interação com bancos de dados, mas está em um nível muito elementar. Para uma discussão mais abrangente sobre design de banco de dados, consulte meu artigo, uma abordagem intuitiva para design de banco de dados.

Mini-Mundos.

Antes de chegarmos aos blocos de construção, vamos dar um momento para entender o termo mini-mundo, porque isso nos ajudará a entender os blocos de construção.

um banco de dados é um modelo de um mini-mundo. Um mini-mundo pode ser um consultório médico, um negócio de varejo, uma biblioteca ou muitas outras coisas. Quando queremos informações sobre o mini-Mundo, recorremos ao banco de dados que o modela.

digamos que você vá ao médico para uma consulta. Quando você diz à recepcionista que tem uma consulta, a recepcionista tentará encontrar sua consulta no modelo (o banco de dados). Se o modelo foi mantido atualizado com seu mini-mundo, ele deve ser capaz de confirmar que você tem uma consulta. Da mesma forma, se uma empresa quiser saber qual de seus clientes de alto volume não fez pedidos nos últimos 6 meses, eles podem recorrer ao modelo de seu mini-mundo se ele for mantido atualizado com esse mini-mundo.Um mini-mundo pode ser um negócio inteiro, ou pode ser uma parte de um negócio, como uma agência bancária, ou o departamento de vendas.A primeira coisa que um designer de banco de dados faz é entender o mini-mundo, porque o trabalho do designer é projetar um modelo desse mini-Mundo. E para entender o mini-mundo, o designer começa identificando os blocos de construção que irão montar um banco de dados.

Os Blocos De Construção

1. Entidades

uma entidade é algo que existe no mini-mundo e que possui características que nos interessam. Por exemplo, em um mini-mundo de matrícula escolar, existem entidades estudantis, entidades do curso, entidades instrutoras e outras. Os alunos têm nomes, endereços, GPAs e outras características que nos interessam. Os cursos têm títulos, créditos, Taxas e outros. E os instrutores têm nomes, endereços, qualificações e outros. As entidades são únicas. Cada aluno é uma entidade única; Há John e Mary e assim por diante. Cada curso é uma entidade única e cada instrutor é uma entidade única.

entidades não precisam ser coisas físicas. Embora você não possa tocar, ver ou sentir o cheiro de uma inscrição, ela existe no mini-mundo de matrícula escolar e tem características que nos interessam, como a data da inscrição, o aluno que se matriculou, o curso em que o aluno se matriculou e a nota final recebida. As vendas são outros exemplos de Entidades que não possuem um componente físico, mas que têm características de interesse para nós (Data de vendas, cliente, vendedor, total do pedido, método de envio, Termos de pagamento, etc.).

2. Entity-Types

entidades do mesmo tipo pertencem a um tipo de entidade. Um tipo de entidade é um conjunto de entidades desse tipo. O tipo de entidade do aluno é o conjunto de todos os alunos. O tipo de entidade do curso é o conjunto de todos os cursos, e o tipo de entidade do instrutor é o conjunto de todos os instrutores.

Entity-types são o conceito mais importante neste post. Eles se tornam tabelas em um banco de dados.

3. Atributos

os atributos de uma entidade são as características dessa entidade que nos interessam. Como já mencionado, os atributos dos alunos incluem nome, endereço, GPA e outros. Os cursos têm nomes, créditos, departamentos aos quais pertencem e outros. E assim por diante com outros tipos de entidade.

Montando os blocos de construção

como esses blocos de construção são representados no banco de dados? Cada tipo de entidade é representado por uma tabela no banco de dados. Nessa tabela, as linhas individuais são as entidades únicas e as colunas são os atributos. Aqui está um exemplo de uma tabela que representa o tipo de entidade do cartão de crédito:

Construção de Regras de bloqueio

Ao trabalhar com blocos de construção, é importante seguir algumas regras, que não só torna mais fácil trabalhar com objetos de banco de dados, mas também evitar que os dados de anomalias (dados de anomalias estão além do escopo deste post, mas são discutidas em detalhes no meu artigo, Uma Abordagem Intuitiva para o Design de Banco de dados).

Regra 1: cada tabela deve representar um e apenas um tipo de entidade.

o banco de dados do Mini-Mundo de matrículas escolares, acima, precisa das seguintes tabelas: Aluno, curso, instrutor, matrícula e outros, um para cada tipo de entidade identificado naquele mini-Mundo. O banco de dados do escritório médico mini-Mundo Precisa de uma mesa de médico, uma mesa de paciente, uma mesa de Consulta, uma mesa de medicamentos e outros. Uma tabela para cada tipo de entidade.

existe uma exceção a esta regra. Prepare – se, aí vem o cérebro twister: Se dois tipos de entidade compartilharem os mesmos atributos e uma entidade em um dos tipos de entidade também for uma entidade no outro tipo de entidade (uma entidade é um membro de ambos os tipos de entidade), os dois tipos de entidade podem ser representados em uma tabela. Aqui está, novamente: um tipo de entidade Professor e um tipo de entidade orientadora podem ser representados em uma tabela, porque os conselheiros também são professores e têm os mesmos atributos (nome professor/orientador, qualificações professor/orientador e outros). Sempre: Um tipo de entidade de pasta e um tipo de entidade de subpasta podem ser representados em uma tabela, porque todas as Entidades de subpasta também são entidades de pasta e compartilham os mesmos atributos (título da pasta, tamanho da pasta, número de itens na pasta, pasta pai e outros). Apenas mais um: os tipos de entidade de funcionário e Gerente podem ser representados na mesma tabela, porque funcionários e Entidades de gerente têm os mesmos atributos e Entidades de gerente também são entidades de funcionários. Essa exceção à regra é examinada mais de perto em outro blog: SQL Server-a consulta de junção automática.

a propósito, observe que esta regra é a razão pela qual a maneira adequada de nomear uma tabela está no singular. As tabelas representam um único tipo de entidade.Regra 2: todas as colunas devem ser atômicas.Você já se perguntou Por que as tabelas de banco de dados podem ter colunas para cidade e estado, mas apenas uma coluna para o endereço? Talvez você tenha se perguntado por que não há uma coluna para o número de endereço, outra para o tipo de rua de endereço (Blvd., Avenida, etc.), outro para o número do apartamento, e assim por diante. Por que essas colunas geralmente são agrupadas em uma única coluna de endereço? A resposta a todas essas questões está na compreensão da atomicidade.Quando dizemos que uma coluna é atômica, queremos dizer que ela não pode ser subdividida e ainda reter significado. Vamos criar uma coluna e chamá-la de MegaAddress que inclui um endereço de rua junto com a cidade e o estado.

Mas porque fazemos pesquisas, o tipo e outras operações em partes da coluna (busca por cidade, tipo pelo estado, imprimir o endereço da parte, e assim por diante), pode-se dizer que as subdivisões de que a coluna tem o seu próprio significado (StreetAddress, Cidade e Estado). Então, MegaAddress não é atômico. Uma mesa melhor seria:

agora, e a coluna StreetAddress? Devemos subdividir isso ainda mais em StreetNumber, StreetName e StreetType? Contanto que não façamos nada significativo com suas subdivisões—se não classificarmos os números das ruas, procurarmos todas as estradas ou avenidas e assim por diante—então a coluna é atômica como está. Mas se fizermos essas coisas, então a coluna não é atômica e então, sim, devemos subdividi-la conforme descrito.

Regra 3: As colunas não podem ser multivalorizadas.

alguns tipos de entidade contêm atributos multivalorados ou um atributo que pode ter mais de um valor. Em uma tabela de Cursos, pode haver um atributo chamado pré-requisitos. Como uma entidade de curso pode ter mais de um pré-requisito, o atributo de pré-requisito é um atributo de vários valores. Quando criamos uma tabela para o tipo de entidade do curso, não poderemos representar o atributo de pré-requisito como uma coluna na tabela. Para representar adequadamente um atributo multivalorado, precisaremos criar outra tabela para ele e relacioná-lo com a tabela original usando um relacionamento um para muitos (os relacionamentos são discutidos em detalhes nos cursos que ensino na interface Tachnical Training SQL100: Introdução ao Transact-SQL e SQL250: Transact-SQL para desenvolvedores e no meu artigo, uma abordagem intuitiva para o design do banco de dados). Outros exemplos de atributos multivalorizados incluem dependentes de um funcionário, qualificações de um médico e assim por diante.

a Regra 3 diz que, para uma determinada entidade (linha em uma tabela), pode haver apenas um valor em cada coluna.

Resumo

Este post introduziu o conceito do mini-mundo como os aspectos de um negócio ou outro ambiente que um banco de dados de modelos. O post também descreveu uma tabela de banco de dados como representando um único tipo de entidade no qual as linhas mantêm as entidades individuais do mesmo tipo e as colunas representam os atributos dessas entidades. Foram introduzidas três regras relativas às tabelas. A regra 1 afirma que uma tabela deve representar um único tipo de entidade. A exceção à regra é quando dois tipos de entidade compartilham os mesmos atributos e entidades em um tipo de entidade são membros do outro tipo de entidade. Nesse caso, ambos os tipos de entidade podem ser representados na mesma tabela. A regra 2 afirma que todas as colunas de uma tabela devem ser atômicas, o que significa que uma coluna não pode ser subdividida e ainda reter significado no mini-Mundo. Finalmente, a Regra 3 afirma que as colunas em uma tabela não podem ser multivalorizadas, o que significa que, para uma determinada entidade (linha em uma tabela), pode haver apenas um valor por coluna.

aproveite!

Pedro Avila

SQL Server Instrutor – Técnico da Interface de Formação

Phoenix, AZ