Instruction manuals

A VFP-SQL Server Application From the Begining

A Book about building Client/Server application with Visual FoxPro and MS SQL Server.
of 38
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A VFP/SQL Server application from the begining - Part I Frederico Tomazetti This article is the first of a series in which I will try to show you how to develop a Visual FoxPro system using the SQL Server database. This article series is targeted to VFP developers who use free tables or tables in a VFP DBC and who are trying to learn new development methodologies. To this task I will use Erwin 4.0 as a modeling tool, SQL Server 2000 and Visual FoxPro 7.0. Here I will make some comments about documentation, data modeling and the use of Erwin 4.0. In this first part we will not concentrate in process and class modeling (UML), but just to model a small database with customer, product and sales order maintenance. It will be a study-focused example for you to understand the process as a whole. Documentation This topic is the weak point of most developers, because as we have all the process in our minds, we leave documentation in a secondary place and, you can be sure, we are always hurt by this. There are several arguments I could use to try convince you about documenting your system right, among them: easier project comprehension by yourself or by another developer, process clarity, etc. But I confess that the argument that convinced me about the need of documenting was: If you don't document your project you will lose time, and mainly, money . Let me explain: When you develop a project for a customer and you don't detail what you'll do, you don't have any control about what you already did and what's pending, and you'll never finish this project. Your customer will always find a little thing missing . Certainly, after everything is working, you have already heard something like this: Where is the module that integrates that with the accounting and payment systems? If you did a proper documentation (and it is signed by your customer) it is enough to show them that this module wasn't included in the project and if they want to build it, it would be another project, with its own negotiation over values, timeframes, etc. Have you seen how you lose time and money if you don't document your working process? I hope that this argument works for you also. The data modeling When I was studying some theories about the modeling process with another developer he told me something that maybe most of us feel: I would need to learn something I don't know to make something I already know how to do . Actually, data modeling has the goal of creating the database with its tables, fields and relationships, concepts that we all already know pretty well by practice. So, why should I do data modeling, why I don't just open SQL Server and create the tables I need for once? If the argument about documentation convinced you, you already have an answer for this question, but in the case you are not convinced yet, try this: with the data model I can create the same data structure in another  database, like Oracle, MySQL, SyBase, etc. That means I won't need to start creating tables if my customer decides some day to switch platforms or if I want to take advantage of the same database for another customer. The modeling process If you read a book about data modeling you will see that everything, or almost everything written there you already do on your daily work. The modeling can be divided in three big parts: Conceptual model:  In this phase a general gathering is made about the customer needs. Here you shouldn't worry about how you'll solve it in your database, nor the tools to use. Just concentrate in understanding the process you'll have to automate, talk with the future users, learn the working of each company's (customer) division, take notes and follow the production processes. After that you'll have a prototype of what needs to be developed. The main error in this phase is to start thinking about the tables that you'll create, and how many IFS or CASES the system will have. Forget about this for now. Logical model:  Now things start to have a more logical shape for us developers. Here we will specify which entities will be part of our data model. For our example those entities will be: CLIENTE (customer), PRODUTO (product), PEDIDO (order) and ITEM (it's a good practice to name always entities in singular) and what relationships exist between them: CUSTOMER puts ORDER and PRODUCT forms ORDER , or if you prefer CUSTOMER buys PRODUCT trough ORDER . In this model we will already define the main attributes of those entities, for instance: CUSTOMER has: Code, name, address and phone. PRODUCT has Code, name, price and barcode, etc. Here you detail how things happen; don't worry about how data will be stored, as theoretically you don't even know yet in which database would be used. Leave the IFS and CASES for later. Physical model:  Here you will finally define what entities and relationships will be transformed into tables, what fields will be considered keys, the size and type of each field, what fields participate in the tables' relationships, and so on. Here we are almost at home . You learned something you didn't know to come to something you already knew. You can be asking yourself: Do I have to make all this separately? The answer: no. Erwin will make a good part of the job, as after defining the logical model, the physical will be automatically generated, but from the conceptual model you can't escape, as they have not invented yet an application that substitutes the human skills for analyzing real world situations. The Erwin 4.0 tool It is not in the scope of this article to show all the features of this tool, as this would surely take a lot of text pages. We will just work with the needed for our database to be modeled. But anyway, there is a tutorial that explains very well the workings of Erwin. When opening Erwin, go to the HELP menu, TUTORIAL option...  ErWin Tutorial Let's do a quick tour trough this tool to identify some basic items: Look at the details circled in red When we click NEW, a dialog opens asking about the major details about the model we will go create. Select the logical/physical model and the SQL Server 2000 database, click Ok, and you'll open a totally blank work area.  These are basically the tools we will need now The A button is used to create our entities; the B set is used to define our relationships. In this case the possible relationships are, respectively: 1 -> N with identified relationship, N -> N and 1 -> N with unidentified relationship. Notice that the figure is formed by a line and a dot in one of the ends; the dot means the N side of the relationship, and in the case of an N -> N relationship there is a dot in each end. When we see this in practice, it would be easier to understand. The C combobox indicates that we are working in the logical model. Later we will switch this combo to work with the physical data model. Click on the Entity tool and click everywhere in the work area Type the name of the entity and press Enter Here we have a detail important enough Notice that attribute_name is located in the entity as if it was a subtitle. That means that this attribute will indicate our future table primary key. It is good to point that we don't know yet where we will go to store our data; we're just defining how they will be stored. We wouldn't worry about the field name, type (character, numeric, date, etc) or size. We can use composite names without any problem. Now we have to press TAB , and thus we will go to the lower part of the entity where we will place the remaining attributes. When you press ENTER again you will go to place another attribute that will make part of the primary key of the future table (you'll have in this case a composite key). As this is not our case now, let's press TAB . Now let's enter the remaining attributes, always pressing ENTER to move to the next line. We can now complete our model with the remaining entities. See how it will look Look at the Attribute_name
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks