Access
 sql >> Base de Dados >  >> RDS >> Access

O projeto de banco de dados do salão de cabeleireiro


Atualizado:22 de janeiro de 2018 por Richard Holowczak


Os materiais a seguir documentam o design e o desenvolvimento de um aplicativo de banco de dados para dar suporte a um pequeno salão de cabeleireiro. O projeto começa com uma descrição do negócio e prossegue através da modelagem conceitual (E-R), modelagem lógica (relacional), modelagem física e, finalmente, implementação de um aplicativo de banco de dados. Notas (Comentários) são fornecidas no final de cada seção para explicar algumas características específicas das etapas que estão sendo realizadas.

Índice

Eu. Cenário de Negócios
II. Modelo ER usando notação UML
III. Conversão para Modelo Relacional
IV. Normalização
V. Criando o esquema de banco de dados com SQL
VI. Aplicativo de banco de dados
VII. Conclusões






.

Eu. Cenário de negócios


Nossa empresa possui e opera um salão de cabeleireiro e manicure no centro de Manhattan há 7 anos. Temos usado planilhas e um livro de registro em papel para acompanhar clientes, compromissos e pagamentos. Gostaríamos de substituir este método manual de acompanhamento do negócio por um banco de dados.

No nosso negócio, os Clientes marcam consultas com o seu cabeleireiro favorito (pessoas que cortam e penteiam o cabelo dos clientes) ou outro funcionário e podem usufruir de uma série de Serviços, como corte/estilização de cabelo básico, coloração do cabelo, madeixas, permanente, tratamento facial, manicure, pedicure, etc. Precisamos acompanhar os materiais (shampoo, tintura de cabelo) e o tempo que levará para concluir cada serviço. Embora cada serviço tenha um preço padrão, promoções e outros fatores podem afetar o preço real oferecido ao Cliente pelo serviço em questão.

Também precisamos acompanhar nossos funcionários, incluindo seu endereço residencial, informações de contato e taxa de pagamento. Precisamos acompanhar as informações de contato de cada Cliente, bem como seu gênero. Para Marcações, precisamos de saber a data e hora da marcação e a que cliente se destina a marcação.

Comentário



Com base na descrição acima, construa um modelo de relacionamento de entidade usando a notação UML que capturará todas as necessidades de dados do negócio.




II. Modelo ER usando notação UML


Com base na descrição acima, desenvolvemos o seguinte modelo Entidade-Relação usando a notação UML.



Comentário


O que gostamos neste modelo:
  • Todas as linhas de relacionamento estão na posição horizontal ou vertical. Nenhuma linha é cruzada.
  • Os nomes dos atributos são escritos sem espaços nos nomes. Nenhuma abreviação é usada.
  • Cada relacionamento tem duas frases muito a partir das quais podemos fazer frases de relacionamento (veja a próxima seção).
  • O diagrama também tem uma "legenda" no canto superior direito para que possamos saber o que o diagrama representa e quem o modificou pela última vez.

Frases de relacionamento


Um Cliente pode ser fazer um ou mais compromissos

Um compromisso deve ser uma reserva para um e apenas um Cliente


Um Serviço de salão pode ser um serviço prestado como um ou mais ServiceRendered

Um ServiçoRenderizado deve ser uma renderização de um e apenas um SalonService

Um funcionário pode ser renderização um ou mais ServiceRendered

Um ServiçoRenderizado deve ser renderizado por um e apenas um Funcionário


Um compromisso pode ser uma reserva para fornecer um ou mais ServiceRendered

Um ServiçoRenderizado deve ser um serviço específico prestado durante uma e apenas uma Consulta


Comentário


As frases de relacionamento devem fazer sentido. Neste exemplo, as frases verbais estão sublinhadas. Os nomes das entidades estão em negrito. A cardinalidade mínima (pode ser para 0 e deve ser para 1) são escritos em itálico. A cardinalidade máxima é escrita como “um ou mais” para * e “um e apenas um” para 1.


Com o modelo ER finalizado, passamos para a próxima etapa – converter o modelo ER conceitual em um modelo relacional lógico.


III. Conversão para modelo relacional



A próxima etapa é converter o diagrama Entidade-Relacionamento em um Modelo Relacional. Durante esta etapa, os Identificadores nas Entidades tornam-se Chaves nas Relações. Os relacionamentos um-para-muitos resultam na cópia de uma chave estrangeira do lado Um para o lado Muitos do relacionamento.


Cliente ( CustomerID (chave), FirstName, LastName, PhoneNumber, Street, City, State, ZipCode )

Serviço de salão ( ServiceID (chave), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Funcionário ( EmployeeID (chave), FirstName, LastName, Street, City, State, ZipCode, PayRate )

Marcação ( AppointmentID (chave), AppointmentDate, AppointmentTime, CustomerID (fk) )

Serviço renderizado ( AppointmentID (fk)(chave), LineItemNumber(chave), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))


Este é o “conjunto inicial de relações”.

Comentário

  • Observe que o ServiceRendered A entidade do modelo ER é dependente de ID, o que significa que precisa de um atributo além de LineItemNumber para formar uma chave composta.
  • As chaves são mostradas com a designação (key) e as chaves estrangeiras são mostradas com a designação (fk).

O próximo passo é normalizar o conjunto inicial de relações.



IV. Normalização



O próximo passo é Normalizar as Relações.

Os passos a seguir para cada relação são:
  1. Escreva a relação incluindo todos os nomes de atributos. Indique chaves e chaves estrangeiras.
  2. Forneça alguns dados de amostra para a relação.
  3. Indique a Chave para a relação e anote todas as Dependências Funcionais .
  4. Percorra as definições de cada forma normal começando com 1NF e indo até BCNF (ou 3NF dependendo dos requisitos do seu projeto).
  5. Se uma relação atender à definição de forma normal, mova para a próxima forma normal superior.
  6. Se uma relação não atender à definição de uma forma normal (por exemplo, ela contém uma dependência de chave parcial ou uma dependência transitiva), divida a relação em duas novas relações.
    Inicie o processo de normalização desde o início com cada uma dessas duas novas relações.

Relação com o cliente


Cliente ( CustomerID (chave) , FirstName, LastName, CustPhone, Street, City, State, ZipCode, Gender )

Dados de amostra
CustomerID Nome Sobrenome Telefone Rua Cidade Estado CEP Sexo
C101 Elia Fawcett 201-222-2222 8989 Smith Road Garfield NJ 07026 F
C102 Ishwarya Roberts 201-222-3333 65 Hope Road Garfield NJ 07026 M
C103 Frederico Fawcett 201-222-2222 8989 Smith Road Garfield NJ 07026 M
C104 Ouro Montanha 201-222-4321 5235 Ironwood Ln Garfield NJ 07026 F
C105 Dheeraj Alexandre 201-222-4545 666 22ª Avenida Bergenfield NJ 07621 M
C106 José Davis 201-333-6789 4200 Bluejay Avenue Bergenfield NJ 07621 F
C107 Faye Glen 201-333-4242 Rua principal 1522 Parque à beira do penhasco NJ 07010 F
C108 Lauren Hershey 201-444-1313 2360 Maxon Road Englewood NJ 07631 F

Chave:CustomerID

FD1:CustomerID -> FirstName, LastName, PhoneNumber, Street, City, State, ZipCode, Gender

FD2:CEP -> Cidade, Estado


1NF:Atende a definição de uma relação

2NF:Sem dependências de chave parciais

3NF:Existe dependência transitiva:CustomerID -> ZipCode e ZipCode -> City, State

Solução:Divida a relação Customer em duas novas relações denominadas CustomerData e ZipCodes:


CustomerData (CustomerID (chave), FirstName, LastName, CustPhone, Street, ZipCode (fk), Gender )

Chave:CustomerID

FD1:CustomerID -> FirstName, LastName, PhoneNumber, Street, ZipCode (fk), Gender

1NF:Atende a definição de uma relação

2NF:Sem dependências de chave parciais

3NF:Sem dependências transitivas

BCNF:Todos os determinantes são chaves candidatas


CEPs( CEP (chave), Cidade, Estado)

Chave:CEP

FD1:CEP -> Cidade, Estado

1NF:Atende a definição de uma relação

2NF:Sem dependências de chave parciais

3NF:Sem dependências transitivas

BCNF:Todos os determinantes são chaves candidatas




Relação de salão de beleza


SalonService ( ServiceID (chave), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )


Dados de amostra:
ServiceID Duração do Serviço Preço do Serviço Materiais de serviço
SV101 Corte de cabelo masculino 20 22h00 Nenhum
SV102 Corte de cabelo feminino 30 32,00 Nenhum
SV103 Corte de cabelo infantil 20 15h00 Nenhum
SV104 Cor de cabelo feminino 60 76,00 Cor, Reagente, Luvas, Pincel de Reagente, Folha
SV105 Estilo de cabelo feminino 45 56,00 Shampoo, Condicionador
SV106 Estilo de cabelo masculino 45 46,00 Shampoo, Condicionador

Chave:ServiceID

FD1:ServiceID -> ServiceName, ServiceDuration, ServicePrice, ServiceMaterials

1NF:ServiceMaterials pode ser tratado como um atributo multivalorado. Neste caso SalonService não está em 1NF.

Solução:Divida ServiceMaterials em uma relação separada.

Para este exemplo, entretanto, manteremos ServiceMaterials como um atributo da relação SalonService.

1NF:Atende a definição de uma relação

2NF:Sem dependências de chave parciais

3NF:Sem dependências transitivas

BCNF:Todos os determinantes são chaves candidatas




Relação com funcionários


Employee( EmployeeID (chave), FirstName, LastName, Street, City, State, ZipCode, PayRate )

Código Funcionário Nome Sobrenome Rua Cidade Estado CEP Taxa de pagamento
E300 Alegria Aveda 46 Easton Avenue Garfield NJ 07026 18h00
E400 Geraldo Geraldo 12 Fortis Blvd. Apto 2A Garfield NJ 07026 22h00
E500 Koy Petruzio 70 Wilard St. Garfield NJ 07026 20h00
E600 Landry Monroe 73 Holly Terrace Parque à beira do penhasco NJ 07010 18h00
E700 Pat Reese 2 Lincoln Place Parque à beira do penhasco NJ 07010 23h00
E800 Inverno Curtimento 215 Elm Avenue Teaneck NJ 07665 23h00

Chave:EmployeeID

FD1:EmployeeID -> FirstName, LastName, Street, City, State, ZipCode, PayRate

1NF:Atende a definição de uma relação

2NF:Sem dependências de chave parciais

3NF:Existe dependência transitiva:EmployeeID -> ZipCode e ZipCode -> City, State

Solução:Divida a relação Customer em duas novas relações denominadas EmployeeData e ZipCodes:


EmployeeData(EmployeeID (chave), FirstName, LastName, Street, ZipCode (fk), PayRate )

Chave:EmployeeID

FD1:EmployeeID -> FirstName, LastName, Street, ZipCode (fk), PayRate

1NF:Atende a definição de uma relação

2NF:Sem dependências de chave parciais

3NF:Sem dependências transitivas

BCNF:Todos os determinantes são chaves candidatas


Nota:Já temos uma relação ZipCodes de quando a relação Cliente foi desmembrada. Então nós reutilizamos essa relação ZipCodes. Não há necessidade de criar uma segunda relação ZipCodes.

Relação de nomeação


Compromisso ( AppointmentID (chave), AppointmentDate, ApotinmentTime, CustomerID (fk) )

Dados de amostra:
ID do compromisso Data do compromisso Hora do compromisso ID do cliente
A400 22/10/2017 11:00:00 da manhã C101
A401 06/11/2017 12:45:00 PM C102
A402 12/07/2017 14:00:00 C106
A403 18/12/2017 15:30:00 da tarde C106
A404 21/12/2017 11:30:00 da manhã C108
A405 31/12/2017 10:00:00 da manhã C107
A406 1/11/2018 15:15:00 C103
A407 1/12/2018 14:30:00 C104
A408 22/01/2018 16:00:00 C105

Chave:ID do Compromisso

FD1:AppointmentID -> AppointmentDate, ApotinmentTime, CustomerID (fk)

1NF:Atende a definição de uma relação

2NF:Sem dependências de chave parciais

3NF:Sem dependências transitivas

BCNF:Todos os determinantes são chaves candidatas

Relação de Prestação de Serviços


ServiceRendered ( AppointmentID (fk)(chave), LineItemNumber(chave), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk) )

Dados de amostra:
ID do compromisso LineItemNumber ServiceID ServiceExtendedPrice Código Funcionário
A400 1 SV104 75,00 E400
A400 2 SV102 25,00 E400
A401 1 SV101 22h00 E500
A402 1 SV104 75,00 E600
A402 2 SV102 30,00 E800
A403 1 SV105 50,00 E300
A404 1 SV105 55,00 E300
A405 1 SV102 30,00 E700
A405 2 SV104 70,00 E700
A405 3 SV105 50,00 E700

Chave:AppointmentID, LineItemNumber

FD1:AppointmentID, LineItemNumber -> ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk)

1NF:Atende a definição de uma relação

2NF:Sem dependências de chave parciais

3NF:Sem dependências transitivas

BCNF:Todos os determinantes são chaves candidatas

Conjunto final de relações



Cliente ( CustomerID (chave), FirstName, LastName, PhoneNumber, Street, ZipCode (fk), Gender)

CEPs (CEP (chave), Cidade, Estado)

Serviço de salão ( ServiceID (chave), ServiceName, ServiceDuration, ServicePrice, ServiceMaterials )

Funcionário ( EmployeeID (chave), FirstName, LastName, Street, ZipCode (fk), PayRate )

Marcação ( AppointmentID (chave), AppointmentDate, AppointmentTime, CustomerID (fk) )

Serviço renderizado ( AppointmentID (fk)(chave), LineItemNumber(chave), ServiceID (fk), ServiceExtendedPrice, EmployeeID(fk))

Comentário

  • Observe que apenas uma relação ZipCodes é necessária. Ele é compartilhado com as relações com clientes e funcionários.
  • Conforme observado anteriormente, o atributo ServiceMaterials não foi normalizado neste exemplo. Talvez isso possa ser feito em uma futura atribuição ou aprimoramento do modelo.



Agora que as relações estão normalizadas, o esquema pode ser criado em um sistema de gerenciamento de banco de dados usando linguagem de consulta estruturada (SQL).


V. Criando o esquema de banco de dados com linguagem de consulta estruturada


Crie uma tabela no banco de dados para cada uma das relações no conjunto final de relações.

O código SQL a seguir cria as seis tabelas e adiciona a restrição PRIMARY KEY a cada uma:

CREATE TABLE ZipCodes( zipcode VARCHAR(12) NOT NULL, city VARCHAR(36), state VARCHAR(4), CONSTRAINT pk_zipcodes PRIMARY KEY (zipcode))CREATE TABLE Customer( CustomerID VARCHAR(10) NOT NULL, FirstName VARCHAR( 35), LastName VARCHAR(35), PhoneNumber VARCHAR(15), Street VARCHAR(35), ZipCode VARCHAR(12), Gender VARCHAR(2), CONSTRAINT pk_customer PRIMARY KEY (CustomerID))CREATE TABLE Appointment( AppointmentID VARCHAR(10) NOT NULL, AppointmentDateTime DATE, CustomerID VARCHAR(10) NOT NULL, CONSTRAINT pk_appointment PRIMARY KEY (AppointmentID))CREATE TABLE SalonService( ServiceID VARCHAR(10) NOT NULL, ServiceName VARCHAR(35), ServiceDuration INTEGER, ServicePrice NUMBER, ServiceMaterials VARCHAR(255) ), CONSTRAINT pk_salonservice PRIMARY KEY (ServiceID))CREATE TABLE Employee ( EmployeeID VARCHAR(10) NOT N ULL, FirstName VARCHAR(35), LastName VARCHAR(25), Street VARCHAR(45), ZipCode VARCHAR(12), PayRate NUMBER, CONSTRAINT pk_employee PRIMARY KEY (EmployeeID))CREATE TABLE ServiceRendered ( AppointmentID VARCHAR(10) NOT NULL, LineItemNumber INTEGER NOT NULL, ServiceID VARCHAR(10) NOT NULL, ServiceExtendedPrice NUMBER, EmployeeID VARCHAR(10) NOT NULL, CONSTRAINT pk_ServiceRendered PRIMARY KEY (AppointmentID, LineItemNumber))

Adicionando chaves estrangeiras


Os seguintes códigos SQL adicionam restrições FOREIGN KEY para vincular as tabelas:
ALTER TABLE Cliente ADICIONAR CONSTRAINT fk_customer_zipcodes FOREIGN KEY (CEP) REFERÊNCIAS CEPs (CEP)ALTER TABLE Funcionário ADICIONAR CONSTRAINT fk_employee_zipcodes FOREIGN KEY (CEP) REFERÊNCIAS CEPs (CEP)ALTER TABLE Compromisso ADD CONSTRAINT fk_customer_appointment REFERÊNCIAS CLIENTE (Customer_appointment) )ALTER TABLE ServiceRendered ADD CONSTRAINT fk_ServiceRendered_Service FOREIGN KEY (ServiceID) REFERENCES SalonService (ServiceID)ALTER TABLE ServiceRendered ADD CONSTRAINT fk_ServiceRendered_Employee FOREIGN KEY (EmployeeID) REFERENCES Employee (EmployeeID)ALTER TABLE ServiceRendered ADD CONSTRAINT fk_ServiceRendered_Appointment FOREIGN KEY (AppointmentID) REFERENCES Appointment (AppointmentID) 

Comentário sobre SQL:
  • A maioria dos DBMS armazena DATA e HORA na mesma coluna. Assim, AppointmentDate e AppointmentTime foram combinados em uma coluna no banco de dados chamada AppointmentDateTime
  • Chaves e chaves estrangeiras devem ter exatamente o mesmo nome e tipo de dados. Por exemplo, a chave CustomerID é VARCHAR(10) na tabela Customer e também VARCHAR(10) na tabela Compromisso.
  • As restrições recebem nomes significativos, como pk_customer para uma chave primária e fk_customer_zipcodes para uma chave estrangeira.
  • Colunas como Número de telefone e CEP devem usar o tipo de dados VARCHAR. Se um tipo de dados NUMBER ou INTEGER for usado, os zeros à esquerda estarão ausentes.


Depois de criar as tabelas e adicionar as restrições de chave estrangeira, o esquema do banco de dados agora se parece com o seguinte:




Visão de relacionamento


Usando a Visualização de Relacionamento em Ferramentas de Banco de Dados, podemos ver os relacionamentos (chaves estrangeiras) entre as tabelas:





Adicionando dados às tabelas usando instruções SQL INSERT

INSERIR VALORES EM CEPs ('07026', 'Garfield', 'NJ');INSERIR VALORES EM CEPs ('07621', 'Bergenfield', 'NJ');INSERIR VALORES EM CEPs ('07010', 'Cliffside' Park', 'NJ');INSERIR VALORES DE CEP ('07631', 'Englewood', 'NJ');INSERIR VALORES DE CEP ('07665', 'Teaneck', 'NJ');INSERIR VALORES DE CLIENTE (' C101', 'Elia', 'Fawcett', '201-222-2222', '8989 Smith Rd', '07026', 'F');INSERT INTO Customer VALUES ('C102', 'Ishwarya', 'Roberts' , '201-222-3333', '65 Hope Rd', '07026', 'M');INSERT INTO Customer VALUES ('C103', 'Frederic', 'Fawcett', '201-222-2222', ' 8989 Smith Rd', '07026', 'M'); INSERIR NOS VALORES DO CLIENTE ('C104', 'Goldie', 'Montand', '201-222-4321', '5235 Ironwood Ln', '07026', ' F'); INSERIR NOS VALORES DO CLIENTE ('C105', 'Dheeraj', 'Alexander', '201-222-4545', '666 22nd Ave', '07621', 'M'); INSERIR NOS VALORES DO CLIENTE (' C106', 'Josie', 'Davis', '201-333-6789', '4200 Bluejay Ave', '07621', 'F');INSERT INTO Customer VALUES ('C107', 'Faye', 'Glenn' , '201-333-4242', '1 522 Main St', '07010', 'F'); INSERIR VALORES DO CLIENTE ('C108', 'Lauren', 'Hershey', '201-444-1313', '2360 Maxon Rd', '07631', ' F');INSERT INTO SalonService VALUES ('SV101', 'Men's Haircut', 20, 22, 'Nenhum');INSERT INTO SalonService VALUES ('SV102', 'Women's Haircut', 30, 32 , 'Nenhum');INSERT INTO SalonService VALUES ('SV103', 'Child Haircut', 20, 15, 'Nenhum');INSERT INTO SalonService VALUES ('SV104', 'Cor de cabelo feminino', 60, 76 , 'Cor, Reagente, Luvas, Pincel de Reagente, Folha'); INSERIR VALORES DO SalonService ('SV105', 'Penteado Feminino', 45, 56, 'Shampoo, Condicionador'); INSERIR VALORES DO SalonService (' SV106', 'Estilo de cabelo masculino', 45, 46, 'Shampoo, Condicionador'); INSERIR NOS VALORES DO FUNCIONÁRIO ('E300', 'Alegria', 'Aveda', '46 Easton Ave.', '07026' , 18);INSERIR VALORES DE FUNCIONÁRIOS ('E400', 'Geraldo', 'Geraldo', '12 Fortis Blvd. Apto 2A', '07026', 22);INSERIR NOS VALORES DE FUNCIONÁRIOS ('E500', 'Koy', 'Petruzzio', '70 Wilard St.', '07026', 20);INSERIR VALORES DE FUNCIONÁRIOS ('E600', 'Landry', 'Monroe', '73 Holly Terrace', '07010', 18);INSERIR NOS VALORES DE FUNCIONÁRIOS ('E700', 'Pat', 'Reese', '2 Lincoln Place', '07010', 23);INSERIR VALORES DE FUNCIONÁRIOS ('E800', 'Inverno', 'Tanner', '215 Elm Ave', '07665', 23);INSERIR VALORES DE COMPROMISSO ('A400', '22/10/2017 11:00:00 AM', 'C101'); INSERIR VALORES DE COMPROMISSO ('A401', '11/06/2017 12:45:00 PM', 'C102'); INSERIR VALORES DE COMPROMISSO ('A402', '12/07 /2017 02:00:00 PM', 'C106');INSERIR NOS VALORES DE COMPROMISSO ('A403', '18/12/2017 03:30:00 PM', 'C106');INSERIR NOS VALORES DE COMPROMISSO ('A404 ', '21/12/2017 11:30:00 AM', 'C108'); INSERIR NOS VALORES DE COMPROMISSO ('A405', '31/12/2017 10:00:00 AM', 'C107'); INSERIR INTO VALORES DE COMPROMISSO ('A406', '01/11/2018 03:15:00 PM', 'C103'); INSERIR NOS VALORES DE COMPROMISSO ('A407', '01/12/2018 02:30:00 PM', 'C104'); INSERIR VALORES DE COMPROMISSO ('A408', '0 22/01/2018 04:00:00 PM', 'C105');INSERT INTO ServiceRendered VALUES ('A400', 1, 'SV104', 75, 'E400');INSERT INTO ServiceRendered VALUES ('A400', 2 , 'SV102', 25, 'E400');INSERT INTO ServiceRendered VALUES ('A401', 1, 'SV101', 22, 'E500');INSERT INTO ServiceRendered VALUES ('A402', 1, 'SV104', 75 , 'E600');INSERT INTO ServiceRendered VALUES ('A402', 2, 'SV102', 30, 'E800');INSERT INTO ServiceRendered VALUES ('A403', 1, 'SV105', 50, 'E300'); INSERT INTO ServiceRendered VALUES ('A404', 1, 'SV105', 55, 'E300');INSERT INTO ServiceRendered VALUES ('A405', 1, 'SV102', 30, 'E700');INSERT INTO ServiceRendered VALUES (' A405', 2, 'SV104', 70, 'E700');INSERT INTO ServiceRendered VALUES ('A405', 3, 'SV105', 50, 'E700');

Comentário sobre amostras de dados

  • Adicionamos dados suficientes para testar as relações entre as tabelas e dar aos desenvolvedores de aplicativos algo para trabalhar.
  • Tenha cuidado com a ordem em que os dados são adicionados. Por exemplo, todos os CEPs precisam ser inseridos primeiro, antes que Cliente ou Funcionário (que usam CEP como chave estrangeira) possam ser inseridos.
  • Ao adicionar dados VARCHAR com aspas incorporadas, use duas aspas juntas. por exemplo, 'Estilo de cabelo feminino'
  • Neste ponto, o esquema do banco de dados está pronto para que os desenvolvedores de aplicativos comecem a trabalhar no design de formulários, relatórios e consultas.

Agora que o esquema de banco de dados foi criado e preenchido com alguns dados de amostra, o aplicativo de banco de dados pode ser desenvolvido.


VI. Aplicativo de banco de dados


O aplicativo de banco de dados consiste em um conjunto de Formulários, Relatórios e Consultas que são vinculados em um Formulário de Navegação.

O Formulário de Navegação é o primeiro formulário que aparece quando o banco de dados é aberto.

Formulário de navegação




Diferentes formulários de entrada de dados e relatórios podem ser exibidos clicando na seleção do lado esquerdo.

Formulário de entrada de dados do cliente




O formulário de entrada de dados do cliente é usado para pesquisar clientes existentes e inserir novas informações de clientes. Os campos Cidade e Estado são preenchidos automaticamente selecionando um CEP na caixa de combinação. O formulário tem vários códigos VBA personalizados para converter o nome e sobrenome para maiúsculas e minúsculas e para gerar um novo e exclusivo ID do cliente quando um campo vazio do CustomerID aparecer após a criação de um novo registro.




Formulário de entrada de dados de serviços de salão




O formulário de entrada de dados de serviço de salão é usado para consultar, atualizar e adicionar novos serviços de salão.

Formulário de entrada de dados de nomeação




O formulário Entrada de Dados de Compromissos é usado para criar um novo compromisso para um cliente. Assim como no formulário Cliente, uma nova ID de compromisso pode ser criada clicando em um campo de ID de compromisso em branco após a criação de um novo registro. O cliente pode ser selecionado na caixa de combinação ID do cliente, conforme mostrado abaixo:



Se este for um novo cliente fazendo um agendamento, o usuário pode clicar no botão Novo cliente para abrir o formulário de entrada de dados do cliente. Depois que as informações do novo cliente forem salvas, o usuário poderá retornar ao formulário de entrada de dados de agendamento e fazer o agendamento.

Formulário de Nomeação e Serviços




O objetivo deste formulário é inserir diferentes serviços associados a um compromisso. Este formulário também pode ser usado para gerar uma fatura para o cliente. O Serviço e o Funcionário podem ser selecionados em suas respectivas caixas de combinação, conforme mostrado abaixo:



Relatório de totais de nomeações de clientes




Este relatório fornece um resumo do número de compromissos e o valor total gasto por cada cliente.


Com base na consulta:
SELECT Customer.CustomerID, FirstName, LastName, SUM(q.TotalSpent) AS TotalSpent, COUNT(q.AppointmentID) AS NumberOfAppointmentsFROM Customer, Compointment, Query_Total_Spent_Each_Appointment AS qWHERE Customer.CustomerID =Appointment.CustomerID AND Appointment.AppointmentID =q. AppointmentIDGROUP BY Customer.CustomerID, FirstName, LastNameORDER BY LastName, FirstName;


E consultar Total_Spent_Each_Appointment
SELECT Appointment.AppointmentID, SUM(ServiceExtendedPrice) AS TotalSpentFROM Compromisso, ServiceRenderedWHERE Appointment.AppointmentID =ServiceRendered.AppointmentIDGROUP BY Appointment.AppointmentIDORDER BY Appointment.AppointmentID;

Relatório de serviços e descontos




Este relatório mostra cada um dos serviços com totais do preço do serviço regular, o preço estendido e uma indicação do valor do desconto aplicado aos serviços prestados no passado.


Com base na consulta:
SELECT SalonService.ServiceID, ServiceName, SUM(ServicePrice) AS TotalServicePrice, SUM(ServiceExtendedPrice) AS TotalExtPrice, FORMAT(1.0 - (SUM(ServiceExtendedPrice) / SUM(ServicePrice)), "0,00%") AS DiscountFROM SalonService, ServiceRenderedWHERE SalonService.ServiceID =ServiceRendered.ServiceIDGROUP BY SalonService.ServiceID, ServiceNameORDER BY SalonService.ServiceID, ServiceName;

Relatório de endereços de clientes




Este relatório mostra os nomes e endereços completos de cada Cliente.


VII. Conclusões


O desenvolvimento de um aplicativo de banco de dados segue um ciclo de vida de desenvolvimento de sistema que começa com a modelagem conceitual e passa por um conjunto estruturado de etapas que incluem modelagem lógica, normalização, implementação física e desenvolvimento de aplicativos. O exemplo do projeto Hair Salon ilustra cada uma dessas etapas principais. No entanto, alguns detalhes não foram totalmente documentados. Por exemplo, algum trabalho adicional pode ser necessário para normalizar a relação dos Serviços de Salão para contabilizar os diferentes materiais usados ​​para cada serviço. Detalhes adicionais de implementação do aplicativo, como outros códigos VBA e descrições mais detalhadas do uso de cada formulário e relatório, também podem ser adicionados.