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:
- Escreva a relação incluindo todos os nomes de atributos. Indique chaves e chaves estrangeiras.
- Forneça alguns dados de amostra para a relação.
- Indique a Chave para a relação e anote todas as Dependências Funcionais .
- Percorra as definições de cada forma normal começando com 1NF e indo até BCNF (ou 3NF dependendo dos requisitos do seu projeto).
- Se uma relação atender à definição de forma normal, mova para a próxima forma normal superior.
- 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.