Projeto
Diagrama ER da Estrutura de Gestão OrganizacionalDiagrama ER da Estrutura de Gestão Organizacional
Fabrício de Medeiros
Conjunto de instruções SQL para criar um banco de dados para gerenciar departamentos, cargos, colaboradores e currículos em uma estrutura organizacional.
CREATE TABLE `dep_departments` (
`id_department` int(11) NOT NULL,
`department` varchar(100) NOT NULL,
`description` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `dep_positions` (
`id_position` int(11) NOT NULL,
`position` varchar(100) NOT NULL,
`id_department` int(11) NOT NULL,
`salary` decimal(10,2) NOT NULL,
`description` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `dep_collaborators` (
`id_collaborator` int(11) NOT NULL,
`collaborator` varchar(100) NOT NULL,
`id_position` int(11) DEFAULT NULL,
`formation` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `dep_curriculum` (
`id_curriculum` int(11) NOT NULL,
`curriculum` text,
`id_collaborator` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
ALTER TABLE `dep_collaborators`
ADD PRIMARY KEY (`id_collaborator`),
ADD KEY `fk_position` (`id_position`);
ALTER TABLE `dep_curriculum`
ADD PRIMARY KEY (`id_curriculum`),
ADD KEY `fk_collaborator` (`id_collaborator`);
ALTER TABLE `dep_departments`
ADD PRIMARY KEY (`id_department`);
ALTER TABLE `dep_positions`
ADD PRIMARY KEY (`id_position`),
ADD KEY `fk_department` (`id_department`);
ALTER TABLE `dep_collaborators`
MODIFY `id_collaborator` int(11) NOT NULL AUTO_INCREMENT;
ALTER TABLE `dep_curriculum`
MODIFY `id_curriculum` int(11) NOT NULL AUTO_INCREMENT;
ALTER TABLE `dep_departments`
MODIFY `id_department` int(11) NOT NULL AUTO_INCREMENT;
ALTER TABLE `dep_positions`
MODIFY `id_position` int(11) NOT NULL AUTO_INCREMENT;
ALTER TABLE `dep_collaborators`
ADD CONSTRAINT `fk_position` FOREIGN KEY (`id_position`) REFERENCES `dep_positions` (`id_position`);
ALTER TABLE `dep_curriculum`
ADD CONSTRAINT `fk_collaborator` FOREIGN KEY (`id_collaborator`) REFERENCES `dep_collaborators` (`id_collaborator`);
ALTER TABLE `dep_positions`
ADD CONSTRAINT `fk_department` FOREIGN KEY (`id_department`) REFERENCES `dep_departments` (`id_department`);
Tabelas criadas:
dep_departments
: Armazena os departamentos, com umid_department
e um nome (department
).dep_positions
: Armazena os cargos, relacionando cada um com um departamento (id_department
), além de possuir um campo de salário e uma descrição.dep_collaborators
: Armazena os colaboradores, com a possibilidade de relacioná-los a um cargo (id_position
) e armazenar sua formação.dep_curriculum
: Armazena os currículos de colaboradores, relacionados porid_collaborator
.
Chaves primárias e estrangeiras:
- Cada tabela tem uma chave primária (
PRIMARY KEY
) em seus respectivos camposid_*
, para identificar registros de maneira única. - Foram adicionadas chaves estrangeiras para garantir a integridade referencial:
- A tabela
dep_collaborators
possui uma chave estrangeira (fk_position
) que referencia a tabeladep_positions
. - A tabela
dep_curriculum
possui uma chave estrangeira (fk_collaborator
) que referencia a tabeladep_collaborators
. - A tabela
dep_positions
possui uma chave estrangeira (fk_department
) que referencia a tabeladep_departments
.
- A tabela
Auto-incremento:
- As colunas
id_department
,id_position
,id_collaborator
, eid_curriculum
são configuradas para serem auto-incrementadas, ou seja, seus valores são gerados automaticamente, sem a necessidade de inserção manual.
Essa estrutura permite gerenciar a relação entre departamentos, cargos, colaboradores e seus respectivos currículos, garantindo que os dados estejam conectados corretamente por meio de chaves estrangeiras.
Sugestões
Aqui estão algumas observações e críticas construtivas para o código SQL fornecido:
1. Uso de NOT NULL
em colunas descritivas:
- Colunas como
description
emdep_departments
edep_positions
estão definidas comoNOT NULL
. No entanto, descrever um departamento ou cargo pode não ser sempre obrigatório, então pode ser interessante permitir valores nulos (NULL
) para esses campos, caso a descrição não seja essencial.
2. Colunas de curriculum
e formation
:
- A coluna
formation
na tabeladep_collaborators
tem tipoVARCHAR(255)
. Para informações de formação, pode haver casos em que mais do que 255 caracteres sejam necessários, principalmente se houver detalhamento de títulos e especializações. O tipoTEXT
pode ser mais apropriado, assim como foi feito paracurriculum
na tabeladep_curriculum
. - Similarmente, o campo
curriculum
está definido comoTEXT
, o que é adequado para armazenar currículos completos, mas, dependendo do tamanho esperado, pode ser necessário ajustar o tipo de dados paraMEDIUMTEXT
ouLONGTEXT
, caso seja esperado um volume maior de dados.
3. Chaves estrangeiras e ON DELETE/ON UPDATE:
- Embora as chaves estrangeiras estejam corretamente definidas, seria recomendável adicionar opções
ON DELETE
eON UPDATE
para definir o comportamento em caso de exclusão ou alteração dos registros referenciados. Por exemplo:ON DELETE CASCADE
: Para garantir que, ao excluir um departamento, todos os cargos e colaboradores relacionados também sejam excluídos automaticamente.ON DELETE SET NULL
: Para casos onde, ao excluir um cargo ou colaborador, os registros relacionados possam ser atualizados paraNULL
.
Exemplo para a tabela dep_collaborators
:
ALTER TABLE `dep_collaborators`
ADD CONSTRAINT `fk_position` FOREIGN KEY (`id_position`) REFERENCES `dep_positions` (`id_position`) ON DELETE SET NULL ON UPDATE CASCADE;
4. Uso de DEFAULT NULL
implícito:
- Nas tabelas
dep_collaborators
edep_curriculum
, algumas colunas são declaradas comoDEFAULT NULL
, o que é redundante, pois oNULL
já é o valor padrão quando nenhuma restriçãoNOT NULL
é aplicada. Portanto, é possível simplificar o código removendo essa parte.
Exemplo:
`id_position` int(11)
5. Falta de índices em campos de busca frequente:
Seria interessante criar índices adicionais em colunas que provavelmente serão usadas em consultas frequentes, como collaborator em dep_collaborators e department em dep_departments. Isso melhora a performance em grandes volumes de dados.
Exemplo:CREATE INDEX idx_collaborator ON dep_collaborators(collaborator);
CREATE INDEX idx_department ON dep_departments(department);
6. Largura de DECIMAL
para salário:
- A definição da coluna
salary
comoDECIMAL(10,2)
permite números com até 8 dígitos inteiros e 2 casas decimais. Dependendo da organização, pode ser necessário permitir valores maiores (especialmente em grandes corporações). Ajustar a precisão para algo comoDECIMAL(12,2)
ou mais pode ser uma melhoria.
7. Normalização e dependência funcional:
- A tabela
dep_curriculum
poderia ser normalizada para armazenar o currículo e informações de formação em uma tabela separada, evitando a repetição de informações, caso um colaborador tenha múltiplos currículos associados.
Abaixo está o diagrama ER (Entidade-Relacionamento) com base no esquema SQL. Este diagrama ilustra as entidades (dep_departments
, dep_positions
, dep_collaborators
, dep_curriculum
), seus atributos, chaves primárias (PK), chaves estrangeiras (FK) e os relacionamentos entre elas.
erDiagram dep_departments { int id_department PK "Chave Primária" varchar department "Nome do Departamento" varchar description "Descrição" } dep_positions { int id_position PK "Chave Primária" varchar position "Nome do Cargo" int id_department FK "Chave Estrangeira para dep_departments" decimal salary "Salário" varchar description "Descrição" } dep_collaborators { int id_collaborator PK "Chave Primária" varchar collaborator "Nome do Colaborador" int id_position FK "Chave Estrangeira para dep_positions" varchar formation "Formação" } dep_curriculum { int id_curriculum PK "Chave Primária" text curriculum "Currículo" int id_collaborator FK "Chave Estrangeira para dep_collaborators" } %% Relacionamentos dep_departments ||--o{ dep_positions : "possui" dep_positions ||--o{ dep_collaborators : "ocupa" dep_collaborators ||--o{ dep_curriculum : "possui"
Explicação do Diagrama
Entidades e Atributos:
dep_departments
:id_department
(PK): Identificador único do departamento.department
: Nome do departamento.description
: Descrição do departamento.dep_positions
:id_position
(PK): Identificador único do cargo.position
: Nome do cargo.id_department
(FK): Referência ao departamento (dep_departments
) ao qual o cargo pertence.salary
: Salário associado ao cargo.description
: Descrição do cargo.dep_collaborators
:id_collaborator
(PK): Identificador único do colaborador.collaborator
: Nome do colaborador.id_position
(FK): Referência ao cargo (dep_positions
) ocupado pelo colaborador.formation
: Formação acadêmica ou profissional do colaborador.dep_curriculum
:id_curriculum
(PK): Identificador único do currículo.curriculum
: Conteúdo do currículo.id_collaborator
(FK): Referência ao colaborador (dep_collaborators
) ao qual o currículo pertence.
Relacionamentos:
dep_departments
"possui"dep_positions
:- Representa que um departamento pode ter múltiplos cargos associados.
- Notação:
||--o{
indica um relacionamento de um-para-muitos (um departamento para muitos cargos). dep_positions
"ocupa"dep_collaborators
:- Indica que um cargo pode ser ocupado por múltiplos colaboradores.
- Notação:
||--o{
indica um relacionamento de um-para-muitos (um cargo para muitos colaboradores). dep_collaborators
"possui"dep_curriculum
:- Mostra que um colaborador pode ter múltiplos currículos associados.
- Notação:
||--o{
indica um relacionamento de um-para-muitos (um colaborador para muitos currículos).
Considerações Finais
Este diagrama ER proporciona uma visão clara da estrutura do banco de dados, facilitando a compreensão das relações entre departamentos, cargos, colaboradores e currículos. Ele é especialmente útil para desenvolvedores, analistas de dados e qualquer pessoa envolvida no design ou manutenção do sistema.
Editar Voltar