ONT-SIZE: 10pt">Desenvolver uma aplicação sólida, rápida e robusta é desejo de qualquer programador. O Delphi 6 e o Kylix 2 facilitam o processo de desenvolvimento, pois trazem uma grande quantidade de recursos e tecnologias, como WebSnap, DataSnap e BizSnap.
Porém, a realidade mostra que muitos desenvolvedores se beneficiariam muito se vissem como construir uma aplicação do início ao fim, utilizando os fundamentos básicos da linguagem, como acesso a bancos de dados SQL, relacionamentos, integridades e cache de dados, utilizando transações e componentes de acesso a dados como TDatasets e TFields. Estes conceitos estão presentes em qualquer nível de desenvolvimento, seja ele desktop, cliente/servidor, multicamadas ou web, portanto é indispensável dominá-los.
Este é o objetivo deste projeto – ensinar você a construir uma aplicação completa e funcional, observando todos os detalhes da linguagem, e utilizando os recursos do Delphi e do Kylix. Mesmo que você seja um programador experiente, poderá encontrar muitas dicas e técnicas que utilizamos em nosso dia-a-dia como desenvolvedores, e que vamos compartilhar com você.
Decidindo pelo sistema
Escolher um sistema para desenvolver durante este projeto não foi uma tarefa fácil. Mas tínhamos uma certeza em mente: o sistema deveria ser simples, pois não queríamos que o leitor leigo em análise tivesse dificuldades logo na modelagem. Algo simples como um sistema para controle de estoque, gerenciamento de biblioteca, contas a pagar e receber ou locadora seria interessante, porém estes sistemas já foram bastante discutidos e há muito material na internet e em livros sobre eles.
Por outro lado, um sistema acadêmico, hospitalar ou para concursos de Vestibular são grandes para quem quer começar do básico, já que envolvem muitas tabelas e relacionamentos, e sua funcionalidade é complexa. Decidimos então por um Sistema de Revenda de Veículos.
Quem não sabe como funciona uma revenda de carros? Quem não sabe como um cliente compra ou vende um carro? É simples! E mesmo quem não conhece os detalhes pode se familiarizar com o básico aqui mesmo.
Dessa forma, nos deteremos nos detalhes da linguagem e da análise de dados, sem nos preocuparmos em desvendar um sistema complexo e seus problemas. Desenvolver o sistema proposto é simples, e ainda assim é possível aplicar quase todos os recursos da linguagem e de banco de dados, os quais você poderá readaptar em seus sistemas.
Funcionamento
Mas como funciona uma revenda de carros? Os dados do cliente são lançados no sistema, juntamente com o veículo que se deseja vender e as características do automóvel. Cada veículo tem uma marca, um modelo e uma cor, além de seus respectivos atributos e acessórios.
Os clientes que desejam comprar um veículo ("clientes pretendidos") também são cadastrados no sistema, juntamente com o veículo de sua preferência. Com base nos dados cadastrados, podemos efetuar buscas para localizar um veículo de acordo com características dele.
Modelagem de dados
O primeiro passo para a construção de uma aplicação sólida e robusta é a modelagem de dados. Existem diversos métodos de modelagem. Entre eles podemos citar o Modelo Entidade-Relacionamento (MER), o Diagrama de Fluxo de Dados (DFD) e a Linguagem de Modelagem Unificada (UML). Usaremos aqui o MER, por ser um método simples, eficiente e de fácil aprendizagem.
Vale dizer que, antes de se utilizar qualquer uma das metodologias citadas, é preciso fazer o levantamento de requisitos do sistema, que é composto por entrevistas a funcionários e direção, visitas à empresa (no caso de sistemas feitos especificamente para uma empresa) ou pesquisas com empresas do mesmo gênero (no caso de sistemas genéricos).
Modelo Entidade-Relacionamento
Para entendermos o MER, é preciso que tenhamos em mente três conceitos básicos: entidades, atributos e relacionamentos.
Uma entidade representa um objeto do mundo real, que tenha existência independente na realidade analisada e que possa ser identificado de forma única em relação aos demais objetos.
Em nosso sistema, Cliente, Modelo e Veículo são exemplos de entidades. Conjuntos de entidades são representados no banco de dados por tabelas (mas estas não serão as únicas tabelas do banco, como veremos depois).
Cada entidade possui um conjunto de atributos. São exemplos de atributos, o nome do cliente (nome_cliente) e sua data de nascimento (data_nasc). Para cada atributo, existe um conjunto de valores válidos, chamados de domínio. Para nome_cliente o domínio seria qualquer caractere alfanumérico; para data_nasc seria uma data válida.
Para uma entidade ser identificada unicamente no conjunto, é preciso que ela possua um atributo (ou um conjunto de atributos) que sejam únicos. A este atributo ou conjunto de atributos, chamamos de chave primária.
Um relacionamento é uma associação entre duas (ou mais) entidades. Como exemplo, podemos citar a relação entre as entidades que criaremos: modelos e marcas (um modelo está relacionado a uma determinada marca). Para que este relacionamento seja possível, é preciso que a entidade modelo possua um atributo que faça referência à chave primária da entidade marca. A este atributo damos o nome de chave estrangeira.
Cardinalidade
Entre os relacionamentos, existe a cardinalidade, que expressa o número de entidades às quais uma entidade pode estar associada. Os relacionamentos podem ter os seguintes tipos de cardinalidade:
Uma-para-um (1 para 1): uma entidade A pode estar associada a no máximo uma entidade B. Em nosso sistema não temos nenhum relacionamento deste tipo.
Um-para-muitos (1 para n): uma entidade A pode estar associada a várias entidades B, mas B pode estar associada a somente uma entidade A. Por exemplo: uma marca está associada a vários modelos.
Muitos-para-um (n para 1): é o inverso do anterior, claro. Uma entidade A pode estar associada a somente uma entidade B, mas B pode estar associado a várias entidades A. Por exemplo: vários modelos estão associados a uma mesma marca.
Muitos-para-muitos (m para n): uma entidade A está associada a qualquer número de entidades B e vice-versa. Por exemplo: um modelo está associado a vários tipos de acessórios, e um mesmo tipo de acessório está associado a vários modelos. Sempre que tivermos um relacionamento do tipo muitos-para-muitos, teremos o surgimento de uma terceira tabela, a qual irá expressar esta relação no banco de dados. Para o caso do relacionamento entre modelos e acessórios no nosso modelo de dados, esta tabela foi chamada de acessorios_veiculo.
Diagrama Entidade-Relacionamento
Definidos os conceitos, passamos agora a desenhar o diagrama ER do sistema (Figura 1). Para isto é preciso que conheçamos os símbolos que expressam cada um dos conceitos vistos anteriormente.
· Retângulos representam os conjuntos de entidades.
· Losangos representam os conjuntos de relacionamentos.
· Linhas unem os conjuntos de entidades aos conjuntos de relacionamentos. Indicam também a cardinalidade dos relacionamentos. Podem ser de dois tipos:
o Uma linha direcionada, do conjunto de relacionamentos A para o conjunto de relacionamentos B, especifica que a cardinalidade é um-para-um ou muitos-para-um. Por exemplo: vários modelos são de uma marca.
o Uma linha não-direcionada, do conjunto de relacionamentos A para o conjunto de relacionamentos B, especifica que a cardinalidade é muitos-para-muitos, ou um-para-muitos. Por exemplo: vários veículos possuem o mesmo tipo de acessório.
Existem ainda outros símbolos que não serão mostrados aqui, pois não são freqüentemente utilizados.
