Hi!!! I am writing because although you said to the other Blanca that write you a email with her exactly direction for the block we have not your email adresse it is for that I am going to put here her adresse: I hope everything will be ok!!
Blanca.DelCastillo.Uni-linz and /blanka.
Thanks very much for all.

It is always difficult for me to say goodbye, but sometimes I must do it.
First of all, I want to say that this “Good bye” is not really that one, so I will be back in the second semester. But this is the end of this class and what I want is to summarize and balance this semester that I have spent here.
I think it has been really positive to be here and live such an experience. I have known a lot of people that I never thought I was going to know. When I came here, in September, I was with the people from my university,
but here I have known people from very different places around the world, and I want to introduce you two of them, which I can say that they are probably my best friends here. They are Suma, from South Africa, and Jesus, from Córdoba (Spain). I have had a great with them here and I want to thank them for being so nice with me.

Also I want to thank the professor Pernsteiner for his comprehension to us, that have difficult with the language.
I have made a lot of good things here. I have travelled around Europe, like Viena, Germany (Munich, Oktoberfest), Italy (Florence, Venice…) and very beautiful places like Hallstaat here in Austria. I remember all of these places very good and enjoy viewing the photos.

Now it´s time to go to Spain, to write some exams and to spend some time with friends and family. I will return in March with the desire to begin again, to find new people, to do new courses, to travel to new places. Actually, I recommend this experience to everybody, and if someone is interested in going to Spain, I can only say that this is a great idea!
Best wishes for everybody and I hope we will see us again!
Julio

3.3.2.Relationale Bank.

3.3.2.1.Daten modelling.

If a relational database to be built, it is first of all a conceptual model that the users of application programs or data required describes developed.

One commonly used method of data modelling is the entity-relationship - model. Through entity relations relationship map, the object classes by rechecked, the relationships between the property by diamond type attribute necessary by the oval. Primary keys are underlined. In dependence of them, as many - to - many - relationships. Relationships can also attribute to have.
3.3.2.2. The business model.
The diagram is a simple business model an instructive book a commercial basis. The "customers" issue repeatedly "sluggish" to the teaching buch handel. Each "contract" can have several "books", each in any quantity ordered. Several "publishers" embarrassed "books" with a "book" with a certain number and title only of a "publishing house" can come as a certain "order" exactly one "customer" is assigned.

3.3.2.3. ER elements.
For graphical representation of the model he has presented ungs following elements:
A lot entiltäts than rectangle. In the book action there is the example entitäts volume customer. On contract. Paper and publishing. As entität be distinct objects from the world. These can be tangible or abstract nature.

An attribute is used as ellipse or district represents. In the book action - as the example has to contribute to attribute No, no release date customers.
Attributes (properties) risieren a entität characters or a relationship (see the relationship between the contribution and to book the amount of property. Order is made, how many exemplares a Paper in a contract to be ordered)

A key or primary key is in red.
Key used for sorting, searching and finding in databases. If an entity not appropriate key, can be added to artificial keys, such as a number. A primary key allows for the identification of any entity. It must be unique. So some may not two different customers the same customer number.

Relations between entities as diamonds drawn. In the diamond, the name of the relationship. To secure it, the reality derived from concepts to choose. A relationship volume is a collection of links to the same kind of linkage entity levels.
1:1 - Relationship: There can be only one element of an entity with one element from another entity connected.
1: n Relationship: An item from an entity with several other elements of a combined entity, but not vice versa.
N: m relationships: Any number of elements of an entity can use any number of other elements of a combined entity.
Special cases:
Part of relationship. In cases of aggregation. Should such collective works in a database abgbildet, so, for example, part of volumes.
Is-a relationship press a specialization or generalization. Example can entity quantities themselves in a lot merged entity. For example, "French textbooks" specialization of the entity quantity "language books."

3.3.2.4 Set of relations (tables)

The presentation of the required object classes in an ER diagram, with their relationships and attributes does not lead directly to the tables of a relational database. To deduce the corresponding tables are building for the tables to be observed, particularly in the so-called. Normal forms are combined.

A table is eibe collection of data about a particular subject, such as books or suppliers. If you have a theme for each separate table, avoiding duplicate data. The backup will be more efficient, and error in the input will be reduced.

In tables are data in columns and rows. Each field in the table book contains the same information for each book, for example, the book price. Each record in the table book contains all the information about a book, for example, book number, publishing brief description, price ...

3.3.2.4. Defining the relations (tables)

The presentation of the need in a facility Let ER diagram, with their relationships and attributes does not lead directly to the tables of a relational database. To deduce the corresponding tables are building for the tables to be observed, particularly in the so-called. Normal forms are combined.
A table is a collection of data on a given topic. If you have a theme for each separate table, avoiding duplicate data. The backup will be more efficient, and error in the input will be reduced.
In tables are data in columns (fields), and rows (records). Each field in the table seben book contains the information for each book.
There are 4 conditions on a table:
-- A table must be unique. This means that at no time two identical records in the table must exist. It contains only one record.
-- A table must atomic attributes and domains.
-- The records are at all times as unsorted.
-- The attribute sequence is never firmly defined.

The following operations are possible with tables:
-- A (blank) Data Set
-- A data (rate) search
-- Data fields
-- Delete a record
-- (Attributes add / delete)


3.3.2.5. Normalizing the tables

With the transfer of the object classes in these tables are then to examine whether they dependencies of the fields themselves. Normalizes, by progressively reviewed whether the tables formed in conditions of normal forms. During this normalization process comes to a reduction of redundancy, but also in parallel to an increase in the number of tables. Whenever discover redundancies will lead to the formation of new tables, through the key fields combined. The adaptation of the tables, on the key fields combined. The adaptation of the tables to the normal forms is the basis of SQL.

1. Normal Form: Remove Repetition group

Each field in the data set may be unique. There are several areas of the same type, they must own them in a relationship be saved.
The transfer of the object class "contract" in a table (relation), the verbal description of the business model accordingly "Each job may contain a number of books, each in any quantity ordered."
As a rule of order in several different books in different amounts, the fields: "Postionsnummer" and "quantity" several times before, was 1 Normal form objects.
The consequence is therefore outsourcing of repeat gruop in a separate table “Auftragspos" and the combination of the tables on the key fields.
The field "no" on the table "mandate" is key field of the table "contract" and is therefore compatible with the box “Auftragspos”. Order number". The names of the two fields differ, but the content is in both cases ident Here is an inevitable redundancy un relational databases, which are also controlled by redundancy and redundancy of not talking.
For the fulfillment of the business model described tasks sin detailed data about the books required.