Sqlserver
 sql >> Base de Dados >  >> RDS >> Sqlserver

Conceitos de design de banco de dados com SQL Server Management Studio (SSMS) Parte 1


Este artigo foi escrito principalmente para iniciantes. Ainda assim, ele cobre alguns conceitos de design de banco de dados interessantes e muitas vezes esquecidos que são igualmente atraentes para profissionais de banco de dados SQL.

A parte atual se concentra nos conceitos de design de banco de dados e seu mapeamento para tabelas, colunas e relacionamentos do Banco de Dados SQL. Se você entender os antecedentes dos bancos de dados e ferramentas que estamos prestes a usar, você projetará seu primeiro banco de dados SQL com confiança.

Pré-requisitos


Antes de prosseguirmos, certifique-se de ter as seguintes coisas:
  1. O SQL Server 2016/2017/2019 Express/Developer edition está instalado em sua máquina
  2. O SSMS (SQL Server Management Studio) está instalado

Além disso, você precisa ter um conhecimento básico de bancos de dados e as ferramentas acima.

Não é um problema se você não tiver as versões mais recentes do SQL Server e do SSMS. No entanto, é altamente recomendável ter as versões mais recentes, se não as mais recentes disponíveis. Você pode obter as versões necessárias nos recursos abaixo:
  • Faça o download do SQL Server 2017 Developer Edition.
  • Faça o download do SQL Server 2019 (como alternativa, para obter a edição mais recente do SQL Server Express/Developer).
  • Ou faça o download de uma edição especializada gratuita do Developer ou Express SQL Server.
  • Faça o download do SSMS (SQL Server Management Studio)

Observe que esses links estão funcionando bem no momento da redação deste artigo. Se a Microsoft decidir substituí-los, faça o download da versão mais recente disponível.

Sobre o design do banco de dados SQL


Para começar a projetar seu banco de dados SQL com o SQL Server Management Studio (SSMS), você deve ter algum plano de projeto em mente.

Não é fácil sem conhecer os conceitos básicos do design de banco de dados. No entanto, depois de obter esses conceitos e sua implementação, você naturalmente começa a seguir os princípios de design. É comum com quase todos os desenvolvedores de banco de dados.

Vamos passar por alguns conceitos básicos de design de banco de dados primeiro. Não é fácil cobrir todos eles em um artigo, mas precisamos de algo para começar.

Entendemos um banco de dados típico em termos das seguintes coisas:
  1. Entidades
  2. Atributos
  3. Relacionamentos

O que é uma Entidade?


Uma entidade é qualquer coisa que a empresa ou um indivíduo gostaria de armazenar em um banco de dados. Por exemplo:
  1. Cliente.
  2. Encomende.
  3. Produto.

Podemos dizer que um Cliente é uma entidade se a empresa deseja armazená-la em uma estrutura de banco de dados para fins transacionais, de análise e de relatórios. Da mesma forma, um Pedido colocado pelo Cliente também é uma entidade se a empresa quiser ver essas informações. Portanto, essas informações devem fazer parte do banco de dados.

No entanto, um Pedido não faz muito sentido sem um Produto . Um Produto oferecido ao Cliente também é uma entidade.

Como a entidade é mapeada para o banco de dados?


Da perspectiva do banco de dados, uma entidade pode ser mapeada para uma tabela. Assim, se uma empresa precisar das entidades Cliente, Pedido e Produto, o desenvolvedor do banco de dados pode mapeá-las como três tabelas.

O que é um atributo?


Um atributo é uma descrição de uma entidade. Por exemplo:
  1. Nome do cliente
  2. Tipo de pedido
  3. Nome do Produto

Se o Cliente for uma entidade, o nome do cliente (CustomerName ) é um atributo. Este atributo descreve nossa entidade (Cliente ). Da mesma forma, Tipo de pedido é um atributo do Ordem entidade e ProductName é um atributo do Produto entidade.

Como o atributo é mapeado para o banco de dados?


Um atributo, como CustomerName, descreve o Cliente tabela e pode ser mapeado para uma coluna nessa tabela.

Uma entidade com vários atributos


Não há problema em uma entidade ter vários atributos. Portanto, podemos ter muitas colunas (atributos) em uma tabela (entidade).

Relacionamentos de entidades


Uma entidade pode ser relacionada a outra entidade por meio de relacionamentos. Uma tabela pode estar relacionada a outra tabela. Existem muitos tipos de entidades ou relacionamentos tabulares:

Relação cliente-pedido (um para muitos)


Um Cliente (entidade/tabela) pode estar relacionado a um Pedido (entidade/tabela) pelos seguintes motivos:
  1. Um cliente pode fazer um pedido.
  2. Um cliente pode fazer muitos pedidos.

O oposto também é verdade:
  1. Muitos pedidos podem ser feitos por um cliente.
  2. Um pedido pode ser feito por um cliente.

Este é um exemplo de um relacionamento um-para-muitos :um cliente pode fazer muitos pedidos e muitos pedidos podem ser feitos por um cliente.

Relação Produto-Pedido (um para muitos)


Um Produto (entidade/tabela) pode estar relacionado a um Pedido (entidade/tabela) da seguinte forma:
  1. Um produto pode ser atribuído a um pedido.
  2. Um produto pode ser atribuído a vários pedidos.

De forma similar:
  1. Muitos pedidos podem ser atribuídos a um produto.
  2. Um pedido pode ter um produto.

Existe uma relação um-para-muitos entre Produto e Pedir .

Relação cliente-produto (muitos para muitos)


Agora a relação entre cliente e produto é explicada da seguinte forma:
  1. Um cliente pode comprar um produto.
  2. Um cliente pode comprar mais de um produto.
  3. Um produto pode ser comprado por um cliente.
  4. Um produto pode ser comprado por mais de um cliente.

Muitos produtos podem ser comprados por muitos clientes, o que significa que o Cliente e Produto relacionamento é muitos-para-muitos .

Observe a ilustração abaixo:

Cenário de Projeto Aluno-Instrutor


Vamos considerar um cenário de design de banco de dados diferente. Você o implementará usando o SSMS (SQL Server Management Studio) na outra parte deste artigo.

Requisitos de negócios


Suponha que você precise projetar um banco de dados que armazene as seguintes informações:
  1. Aluno(s).
  2. Instrutor(es).
  3. Alunos que receberam um instrutor.
  4. Instrutores designados para os alunos.

Análise Preliminar


Observando atentamente, você descobrirá algo bastante interessante sobre os requisitos acima. “Os alunos que alocaram um instrutor” e “Os instrutores que foram designados para os alunos” são o mesmo requisito.

Pode ser frequente que dois requisitos de aparência diferente sejam os mesmos no contexto do projeto de banco de dados.

Identificar entidades


As seguintes entidades podem ser extraídas imediatamente dos requisitos:
  1. Aluno
  2. Instrutor

No entanto, mais uma entidade serve para nos fornecer informações sobre os instrutores alocados aos alunos.

Vamos relembrar o primeiro exemplo em que usamos uma tabela de Pedidos – muitos clientes podem comprar muitos pedidos na relação Cliente-Pedido. É semelhante ao nosso aluno-instrutor relação tabular – muitos instrutores podem ser alocados para muitos alunos.

Identificar atributos


Podemos escolher atributos úteis para as entidades identificadas, de acordo com esse cenário de pedido do cliente:
  1. Aluno:ID do aluno, nome.
  2. Instrutor:ID do instrutor, nome.
  3. Aluno-Instrutor:ID do Aluno-Instrutor, ID do Aluno, ID do Instrutor.

Relações de identidade:


Identifique os relacionamentos das entidades:
  1. Aluno -> Aluno-Instrutor (um para muitos).
  2. Instrutor-> Aluno-Instrutor (um para muitos).
  3. Aluno -> Instrutor (muitos para muitos).

Lembre-se de que sempre usamos uma tabela intermediária para resolver o relacionamento muitos-para-muitos. É por isso que trouxemos a entidade Aluno-Instrutor para o plano.

Mapeando entidades e atributos para tabelas e colunas


Agora podemos mapear as entidades para tabelas. Assim, vamos criar as três tabelas a seguir:
  1. Aluno.
  2. Instrutor.
  3. Aluno-Instrutor.

Da mesma forma, os atributos dessas entidades, quando mapeados para as colunas, serão os seguintes:
  1. Aluno:StudentId, Nome.
  2. Instrutor:InstructorId, Nome.
  3. Aluno-Instrutor:StudentInstructorId, StudentId, InstructorId.

Observe a ilustração abaixo:

Parabéns! Você aprendeu com sucesso os conceitos de design de banco de dados. Estamos familiarizados com entidades, atributos e relacionamentos e as etapas para mapeá-los para tabelas e colunas no banco de dados.

Os próximos artigos guiarão você pelas etapas de criação de banco de dados usando o SSMS (SQL Server Management Studio).

Coisas para fazer


Agora que você entende o básico do design de banco de dados, tente as seguintes coisas para melhorar ainda mais suas habilidades:
  1. Tente adicionar outra entidade chamada Fornecedor com os atributos SupplierId e SupplierName. Verifique se você consegue identificar corretamente as seguintes relações:
    1. Pedido do fornecedor;
    2. Fornecedor-Cliente;
    3. Fornecedor-Produto.
  2. Projete um banco de dados junto com a identificação de entidades, atributos e relacionamentos para uma biblioteca. Dica:Os livros são entregues aos membros e os membros emprestam livros da biblioteca. Membro, Livro, Emitido podem ser entidades.
  3. Identifique o tipo das seguintes relações tabulares para as entidades mencionadas acima:
    1. Emitido por Membro;
    2. Livro Emitido;
    3. Livro de Membros;
    4. Membro do livro.

Leia também


Aprenda o design de banco de dados com o SQL Server Management Studio (SSMS) – Parte 2