O que é um esquema relacional? Como criar um banco de dados eficiente?
Não há uma estrutura de banco de dados única que seja sempre mais eficiente do que qualquer outra. Isto porque o tipo e quantidade de dados armazenados muda a estrutura ótima do banco de dados.
No entanto, há uma grande diferença entre construir um banco de dados otimizado para performance versus um que é otimizado para o volume de dados.
Usando esquema relacional no MySQL, você pode criar um banco de dados que é otimizado para o volume de dados. Isto é ideal em situações onde o custo de armazenamento, processamento e memória é proibitivamente caro.
Embora este não seja mais o caso da eletrônica padrão, ainda há muitas situações onde programadores e desenvolvedores gostariam de usar esquema relacional. Embora armazenamento, poder de processamento e memória sejam baratos para usuários de computadores convencionais, estas coisas são massivamente caras no mundo da computação quântica.
Tambem, um esquema relacional é importante em bancos de dados MySQL que dependem de relações para gerar significado. Registros acadêmicos e de funcionários, por exemplo, podem ser prontamente considerados como redes de relacionamentos melhor descritos usando esquemas relacionais do que, por exemplo, bancos de dados de valor chave ou gráficos.
O esquema relacional é o elemento primário do banco de dados relacional. Estes bancos de dados são gerenciados usando linguagem e estrutura que é consistente com a lógica de primeira ordem. Isto permite a gestão da base de dados com base nas relações entre entidades, tornando-as fáceis de organizar de acordo com o volume.
Esquema relacional refere-se aos meta-dados que descrevem a estrutura dos dados dentro de um determinado domínio. É o esquema de uma base de dados que delineia a forma como a sua estrutura organiza os dados em tabelas.
Por exemplo, se o seu banco de dados contém registros de empregados de uma grande empresa, então você pode ter relações de entidade descrevendo cada empregado como uma entidade forte como tal:
- Nome do funcionário
- Número de identificação
- Endereço
- Conhecimento de habilidades do funcionário
- Data de contratação
- Anos de serviço
Neste exemplo, você teria dois atributos de dados de esquemas relacionais. Primeiro, você teria o atributo Empregado, que é a chave primária da tabela (já que tudo está relacionado ao empregado) e um atributo Endereço, que é um atributo composto composto por diferentes elementos.
O atributo Endereço consistiria nos seguintes valores:
- Cidade
- Rua
- Número de endereço
- Código Postal
Sabendo isto, você está pronto para mapear um diagrama de relação de entidades para o esquema relacional. Ele gostaria de se parecer com isto:
- Funcionário (Nome, Número de Identificação, Número de Endereço, Rua, Cidade, Código Postal, Data de Contratação)
- Skillset do Funcionário (Número de Identificação, Skillset)
Você deve notar que Anos de Serviço está excluído desta lista. Isso porque é um atributo derivado que pode ser calculado subtraindo a Data de Contratação da data atual. O motivo pelo qual o Employee Skillset tem seu próprio esquema é porque ele é um atributo multi-valorizado.
Para esquema relacional, cada tipo de entidade se torna sua própria tabela, e cada atributo multi-valorizado é uma coluna dentro dessa tabela. Atributos derivados podem ser ignorados com segurança, enquanto atributos multivalorizados tornam-se tabelas separadas.
O método para converter tipos de entidades fracas para o esquema relacional é similar ao processo descrito acima, exceto que tipos de entidades fracas tornam-se tabelas próprias e a chave primária da entidade forte atua como uma chave estrangeira na tabela.
Isso significa que para a entidade forte Empregado, você criaria uma chave primária composta composta pela chave estrangeira Dependente e a chave da própria entidade fraca. Isso faria o esquema ficar assim:
- Empregado (Nome, Número de Identificação, Número de Endereço, Rua, Cidade, Código Postal, Data de Contratação)
- Dependente (Empregado, Número de Identificação, Nome, Endereço)
A correlação aqui é entre o Número de Identificação na tabela Empregado e o elemento Empregado da tabela Dependente.
Com este trabalho feito, você está pronto para começar a converter relacionamentos. Para isso, é necessário compreender a cardinalidade e o grau de cada relacionamento.
- Existem três possíveis cardinalidades – 1:1, 1:M, 1:N
- Existem três possíveis graus – unário, binário e ternário.
Visto o exemplo acima, Empregado poderia ser combinado com uma nova tabela de Departamento para formar um relacionamento binário 1:1. Se o empregado administra um departamento específico, então ele ou ela pode ser descrito como um participante parcial, enquanto o departamento seria descrito como um participante total.
O esquema relacional ficaria assim:
- Funcionário (Nome, Número de Identificação, Número de Endereço, Rua, Cidade, Código Postal, Data de Contratação)
- Departamento (Número de Identificação do Gerente, ID do Departamento, Nome, Endereço)
Neste caso, a chave primária do participante parcial passa a ser a chave total do participante estrangeiro. O número de identificação do gerente está correlacionado com o número de identificação do funcionário apropriado.
Esta mostra uma parte importante da criação do esquema relacional. A chave primária de um participante num relacionamento binário 1:1 pode tornar-se uma chave estrangeira no outro. Outra maneira de descrever a relação acima seria usando Manages como a chave estrangeira em Employee, correlacionando com a chave primária ID do Departamento em Department.
Um exemplo de uma relação 1:N Binário seria aquela entre um Professor ensinando um Assunto. Em uma determinada sala de aula, os professores podem ensinar mais de um Assunto para uma variedade de alunos, mas todos os Assuntos compartilham a mesma relação com o professor.
Na relação binária 1:1 acima, cada departamento tinha um gerente único. Com este relacionamento binário 1:N, um número variável de alunos pode compartilhar o mesmo professor. A chave primária do professor seria a ID do professor, que se correlacionaria com a chave estrangeira do Assunto, em Teacher.
Para descrever uma relação binária M:N, imagine um aluno se matriculando em um curso. Crie uma nova tabela descrevendo o Aluno e outra descrevendo o Curso. Ambas as tabelas estão relacionadas através do acto de inscrição, e ambas apresentam chaves estrangeiras.
- A chave estrangeira para Aluno é o ID do Aluno.
- A chave estrangeira para Curso é o ID do Curso.
A chave primária da nova tabela é a combinação das chaves estrangeiras de cada entidade. Você a descreveria como (ID do Aluno, ID do Curso). Este é um único esquema binário M:N que liga estudantes individuais a cursos.
Isto funciona porque os IDs são, pela sua natureza, criados com o propósito de serem chaves estrangeiras em bases de dados relacionais.
Você pode usar um esquema relacional para descrever relações de auto-referência. Por exemplo, dois funcionários que são casados um com o outro poderiam apresentar a chave estrangeira do Cônjuge. Para ambas as chaves estrangeiras destes empregados, a referência será a identificação do outro empregado, que é a chave primária da respectiva tabela de cada empregado.
Esta também funciona no esquema de relacionamento com uma cardinalidade 1:N. O campo chave primária em si se tornaria a chave estrangeira da mesma tabela, neste caso. Isto é o mesmo que um esquema unário 1:1.
Por exemplo, um Empregado que é o gerente de um Subordinado pode ter gerente como sua chave estrangeira. Neste caso, o Employee ID seria a chave primária na mesma tabela.
A auto-referência de uma relação M:N requer duas tabelas. Uma deve representar a entidade em questão e a outra deve representar a relação M:N.
Imagine um funcionário que é responsável por garantir a qualidade de um determinado produto ou serviço. Esta relação teria que incluir tanto o Fiador quanto o Beneficiário como chaves estrangeiras que se combinam para se correlacionar com a identificação do Empregado da tabela Empregado. Tanto o Fiador como o Beneficiário actuariam como chaves primárias e estrangeiras dentro da recém criada tabela de esquemas relacionais.
Embora as relações binárias e unárias sejam simples de descrever usando o esquema relacional com uma ou duas tabelas. Tabelas unárias requerem uma terceira, nova tabela.
A chave primária desta nova tabela consiste na chave estrangeira de cada entidade participante, adicionada em conjunto. Isto significa que a nova tabela deve conter três chaves estrangeiras para se correlacionar com.
Por exemplo, a relação entre um médico e seu paciente na verdade consiste em três entidades: O Doutor, o Paciente, e o Medicamento. Para descrever corretamente esta relação como um esquema relacional, você deve atribuir chaves estrangeiras a cada uma dessas entidades e correlacioná-las a uma nova tabela intitulada Prescrição.
Esta é uma forma simples de visualizar a forma como uma tabela ternária funciona. A chave primária da tabela de Prescrição recentemente criada é (Doutor ID, Patient ID, Drug ID). Qualquer esquema que não inclua estas três importantes peças de dados está faltando uma parte importante do enigma.
Esta abordagem permitiria que um gerente de banco de dados criasse um arquivo organizado de prescrições que contabilizasse tipos específicos de medicamentos, imediatamente correlacionado com os nomes dos pacientes que os estão usando e oferecesse os nomes dos médicos que os prescreveram.
Por uma questão de completude, você pode desejar adicionar a data de validade à tabela de Medicamentos para que estes dados estejam disponíveis dentro da matriz principal. Você pode adicionar a Próxima Consulta ou Data de Recarga à tabela de Prescrição. Você logicamente gostaria de adicionar Data de Nascimento, Endereço e outros dados relacionais importantes à tabela de Pacientes.
Todas estas ferramentas combinam para tornar possível a criação de bancos de dados orientados a relacionamentos no MySQL. Você pode praticar fazer seus próprios bancos de dados MySQL online com qualquer navegador usando SQLDBM.