Banco de Dados: Criação do BD via SGBDs a partir do Modelo Lógico
Análise de Requisitos
Modelo Conceitual
Modelo Lógico
Modelo Físico
Lembre-se que estamos lidando com um método de modelagem de dados que envolvem entidades. Portanto, suas representações são efetivadas por meio do uso de tabelas.
Ao descermos mais um nível de abstração do modelo lógico chegamos ao Modelo Físico. Caso for reduzido em mais um passo o nível de abstração estaríamos no patamar de hardware
O ponto de partida do modelo físico é o modelo lógico
O objetivo de modelo físico é a criação de estrutura de dados físicas no SGBD os quais são responsáveis pelo armazenamento de dados
Outro objetivo é auxiliar na escolha do SGBD
O modelo físico não se preocupa com aspectos que não tenha ação direta na programação de aplicações com SGBD
O processo inicia a com a definição de quais são os tipos de dado previstos no modelo lógico para comportar os valores dos tributos
A Structured Query Language (SQL) é a linguagem padrão para trabalhar com banco de dados relacionais nos diferentes SGBDs disponíveis no mercado.
A primeira versão, originalmente chamada de Structured English Query Language (Sequel)
A linguagem surge no início da década de 70 a partir dos estudos de Codd e o departamento de desenvolvimento da IBM
A SQL usa uma combinação de construtores em Álgebra e Cálculo Relacional (tuplas)
Uma transação é uma série de operações sequenciais realizadas no Banco de Dados. As operações da transação compõem uma unidade de trabalho, ou seja, é como se fossem uma coisa só.
O SQL é composto por um conjunto de linguagens que possibilita a definição, pesquisa, manipulação dos dados e outros recursos como configuração de acesso e segurança.
DDL - Data Definition Language - Linguagem de Definição de Dados.
DML - Data Manipulation Language - Linguagem de Manipulação de Dados.
DQL - Data Query Language - Linguagem de Consulta de dados.
DTL - Data Transaction Language - Linguagem de Transação de Dados
DCL - Data Control Language - Linguagem de Controle de Dados.
No mercado brasileiro existem diversas micro-empresas que produzem e/ou revendem (on-line ou off-line) acessórios femininos tais como brincos, colares, pulseiras, saias etc. Uma característica marcante é a imensa proporção de players que produzem seus produtos. Nos casos em que há fabricação própria, ocorre uma maior exigência no controle dos processos mesmo para produtos não industriais como o artesanato. A razão vem do aumento de complexidade gerada pelo fluxo de processo da linha de montagem. Este por sua vez envolve o dispêndio de mão de obra somado ainda a armazenamento e consumo de matéria prima. Caso a empresa faça apenas revenda, então boa parte da complexidade é eliminada ou reduzida.
Para que um sistema incorpore as características desse segmento e concomitantemente mantenha um caráter genérico para comportar a sua heterogeneidade, ele deve atender aos seguintes pontos:
Produção: Controle simples e objetivo da confecção focado nas etapas de produção e menor preocupação com o estoque e consumo de matéria prima
CRM: Cadastro de clientes que permita incluir os contatos de redes sociais, medidas e tamanhos das clientes, informações de frete para o envio dos produtos, histórico de compras e wish list
Logística: Armazenamento dos pedidos com todos os seus itens para ser enviados as clientes. Esses dados são vitais para alimentar um sistema de gestão para o controle dos envios das encomendas
Para que um sistema incorpore as características desse segmento e concomitantemente mantenha um caráter genérico para comportar a sua heterogeneidade, ele deve atender aos seguintes pontos:
Vendas: Auxiliar no controle de produtos que não possuem produção própria. Admitir um gerenciamento de preços por duas vias, a de quem produz e de quem vende. Gestão dos pagamentos de comissões dos anunciantes.
Marketing: Alta disponibilidade de dados que permitam futuramente a modelagem de algoritmos de machine learning envolvendo matriz de correlação das saídas dos produtos para para sugestão e categorização. Detecção e predição dos itens mais procurados e desejados bem como detecção de padrões de consumo mediante perfis em rede social e histórico com a marca
Financeiro: Gerar subsídios para relatórios gerenciais envolvendo a lucratividade, liquidez e risco por: peça, volume, tempo de produção. Categorização de clientes e produtos por rentabilidade e volume. Projeção de fluxo de caixa.
A partir do modelo Lógico, estamos aptos a iniciarmos o desenvolvimento do nosso modelo Físico.
A forma mais prática para acessar o MariaDB é por meio do terminal Linux e digitar os comandos mariadb
ou mariadb -u usuario -p
. Lembre-se que ao final de toda linha de comandos SQL deve ter ‘;’ (ponto-e-vírgula) ou “\g”.
O primeiro passo é criar usuários com acesso ao banco e com suas respectivas permissões.
Conectar ao servidor MariaDB e apontar o banco de dados ao qual iremos trabalhar.
Criar as tabelas conjuntamente com os atributos e seus respectivos tipos de dados.
Incluir as constraints como foreign keys (chaves estrangeiras), unique, not null, default value, auto_increment etc.
Criar as views para pesquisas futuras e verificar a necessidade de criação de indexes.
Desenvolver as stored procedures e os triggers.
Para criar um usuário local e sua senha digite o comando abaixo
Para definirmos quais bancos e quais tabelas o usuário terá permissão de acesso e quais operações poderá realizar, execute o seguinte comando
A diretiva ALL PRIVILEGES
concede todos os privilégios ao usuário. O símbolo *
representa todos elementos listados (notação regex) tanto para DATABASE
quanto TABLE
.
Ao conectar e acessar o MariaDB com as novas credenciais, podemos criar o banco através do comando abaixo.
Verificamos também todos os bancos existentes após a criação. Na sequência apontamos para o banco de dados ao qual iremos trabalhar. Para isso, digite
Terminada a etapa anterior, temos definido:
usuários com login e senha
os privilégios de acesso
banco de dados criado
A próxima etapa é a criação das tabelas com suas respectivas relações e atributos no banco de dados que criamos utilizando linguagem de definição de dados do MariaDB.