South American Technological

Database

Database design

Produced by:
Jhonny Peñaloza

Andrés Pesantez

Alex Sanmartín

Jorge Enderica

1
 2009
INDEX

Page.

Cover
Index............................................................................................II
Introduction

CHAPTER I

Theoretical Framework

1. Database....................................................5

1.1 advantages.....................................................5
1.2 Types of Databases...........................................................5

2. The DBMS.............................................6

2.1 DBMS Schema……………………………………………………….…..…7

3. Database Design…………...............8
3.1 identification of entities..................................................9

3.2 Entity Relationship............................................................9

3.3 Identification of tables......................................................9

3.4 Key Identification……………………………………………………...9

4. Data Types, Length.................…………..…………………….………………………..…10

2
 5. Functional Dependency…………………………….………..…..….10

6. Normalization………………………………………………...…..………………..……11

6.1 First Normal Form……………………..…….……………….11

6.2 Second Normal Form…………………….…………11

6.3 Third Normal Form………………………….……........11

4th Normal Form…………………………….……12

7. Relationship of Tables Relational Model.................................................12

CHAPTER II

Development

1. Identification Entities……………………..…………………………………….…13

2. Relationship Entities………………………………………..………………..……13

3. Normalization…15

First Normal Form……………………..…….……………….16

4.2 Second Normal Form……………………..…….……………….17

3rd Normal Form……………………..…….……………….19

4.3 Fourth Normal Form……………………..…….……………….20

4. Identification of Tables….21

5. Relational Model………..22

CHAPTER III

1. Conclusiones.……………………………………………………………………………23

2. Recommendations….24

3. Glossary….25

4. Bibliography..........................................................…………..26

3
 5. Annexes…............27

Introduction

Currently, the company handles a large amount of data, as this data is a key piece in the
the company's operation must have them stored in a database and managed by
an automatic way to be able to treat them and handle them entirely correctly in
the aspects that the company carries out to avoid wasting time and money
valuable.
One of the crucial steps in building an application that handles a database is the
database design.
If the tables are not defined properly, we may have many inconveniences at the time.
to execute queries on the database to try to obtain some information.
The functionality of the database should not vary significantly if, for example, our
The database has only 20 records, or 1000 records, it is important to ensure that our database
The data structure is designed correctly to ensure efficiency and to be usable.
for a long time.
This work will provide the basic parameters for designing a database.
The complexity in the database design will depend on how much and what information will be.
stored in the same and is unique for each case, but all will be based on the same principles
what we will notice in the present document.

4
 Theoretical Framework

CONCEPTS AND DEFINITIONS.

Database.

A set of related information stored in auxiliary memory that allows

shortcut and a set of programs that manipulate those structured data and
organized independently of their use, and which is used so that the user with
need for information I consulted in real time.

Advantages of Databases.

1. Data independence and processing. Change in data does not imply change in
programs and vice versa (Lower maintenance cost).

2. Coherence of results. Reduce redundancy.

3. Improvement in data availability. There is no data owner (But they are not public).
we save description.

4. Compliance with certain standards. Security restrictions, access (Users to

data), operations (Operations on data).
[Link] advantages: More efficient storage management.

Types of Databases.

Due to the variability of the stored data

• Static. Read-only, they are historical.

• Dynamic. They change over time.

By Content.

• Bibliographic. Information about the main source

• Full text. Contents

Data Management Model.

• Hierarchical. Inverted tree form, it can represent two types of relationships between the
data: one-to-one relationships and one-to-many relationships, there is redundancy.
• Red. This model allows for many-to-many representation, in such a way that
any record within the database can have several occurrences greater than

5
 He. The network model avoids redundancy in information, through the incorporation of a
a type of record called the connector.
• Relational. This model is being used more frequently in practice, due to the
advantages it offers over the two previous models, among them, the quick understanding
from users who do not have in-depth knowledge about Database Systems
Data.
• Multidimensional. Similar to the relational, this stores database structures.
• Object-oriented. Relates the state and behavior of data.
• [Link] text indexing
• Distributed. Stored on several computers
• Deductive. Through inferences (applied to the scientific environment)

We will focus on the relational form which is the most commonly used.

DBMS (Database Management Systems)

The DBMS: is a set of programs that handle the creation and all accesses.
to databases, are a very specific type of software, dedicated to serving as an interface between the
database, the user and the applications that use it, is composed of:

• DDL (Data Definition Language): Data Definition Language. Through this, the
DBMS identifies the descriptions of the elements of the schemas and stores them
description of the schema in the DBMS catalog. Through this, the DBMS specifies the
conceptual and internal schema (Stored Database).

• DML (Data Manipulation Language): Data Manipulation Language. Allows the

manipulation of Insert, Delete and Modify operations.

• SQL: Query Language.

Examples: Oracle, Access, Informix, SQL Server.

The capacity of DBMS is defined by its engine, that is, the amount of data it can handle.
able to drive.

Objectives.

• Physical and logical independence of data. Data independence consists of the

the ability to modify the scheme (physical or logical) of a database without having to
make changes to the applications that rely on it.

• Minimum redundancy. In those cases where it has not been possible to eliminate the
redundancy, it will be necessary to monitor that the information appearing repeatedly

6
 • Data integrity. It involves taking the necessary measures to ensure the
validity of the stored data.

• Concurrent access by multiple users. It must control this access.

concurrent with the information, which could lead to inconsistencies.

• Optimized complete queries. It is desirable to minimize the time the DBMS takes to
give us the requested information and store the changes made.

• Access security and audit. They must ensure that this information is available.
secure against malicious users who attempt to read confidential information.

• Backup and recovery. They must provide an efficient way to perform copies of
backup of the information stored in them, and to restore from these copies the
data that may have been lost

• Access through standard language. It can be accessible with common language.

Purpose

The general purpose of database management systems is to handle

clearly, simply, and orderly a set of data that will subsequently be converted
in relevant information, for a good handling of the data.

Diagram of a DBMS

7
Users of a Database Management System

• DBA staff
• Sporadic Users
• Application Programmers
• Parametric users

DATABASE DESIGN

It is the basis of the entire process since if the design is solid, implementing it will not present us with
major problem.

It essentially consists of the following processes:

1. Identification of Entities
2. Relationship of Entities
3. Identification of tables
4. Identification of keys
5. Data types and length
6. Normalization
[Link] model

Equivalent relational terminology

Rule = table or file
Tuple = record, row or line
8
 Atributo = columna o campo
Key = key or identification code
Candidate Key = minimal superkey
Primary Key = chosen candidate key
Foreign key = external key or foreign key
Clave Alternativa = clave secundaria
Dependencia Multivaluada = dependencia multivalor
RDBMS = From English Relational Data Base Manager System which means, System
Relational Database Manager.
1NF = Means, First Normal Form of the English First Normal Form.

Entity Identification.

Something about which we store data.

A person, place, thing, or concept that it has characteristics of interest for the
company.

Relationship of Entities.

Identify which entities are involved in the processes, and for the practice, they intertwine with
a word that identifies the process and directional arrows. Example:

Client Receive Invoice

Table identification.

It is to generate the table for each entity defining the fields or records that are
necessary for each of them.

Identification of keys.

A primary key is that column (it can also be two columns or more) that
identify only that row. The primary key is an identifier that will be unique
for each row. In a table, we may have more than one key, in that case it can

9
choose one to be the primary key, the other keys are the candidate keys. In addition
it is the possible primary key.
A foreign key is that column which, existing as a dependent in a table, is to
primary key in another table.
An alternative key is that candidate key that has not been selected as a key.
primary, but can also uniquely identify a row within a table.
Example: If in a customer table we define the document number (customer id) as
primary key, the customer’s social security number could be an alternate key.
In this case, it was not used as a primary key because that data may not be known.
in all clients.
A composite key is a key that consists of more than one column.

Pk =clave principal

Fk =clave foránea

Nn = not null

Uk = unique

Ck =clave de chequeo

Data type, and length.

This defines the type of information that will be stored in each field.

It can be defined in various types such as text, numeric, monetary, date, etc.

We also need to define the length of the field, that is, what load it would support, for example.
we define the fieldname of type text of length 30, this tells us that the
field name will store text data up to 50 characters.

Functional dependency

A functional dependency is a connection between one or more attributes. For example, if

We know the value of DateOfBirth, we can know the value of Age.

It is written using an arrow:

FechaDeNacimiento Age

Properties: Armstrong's Axioms

10
Reflexive. It helps us to obtain records that are directly related to the
main key. For example:

Account Number

Name

Augmentative. In order to obtain additional records related directly to the

primary key. For example:

Account Number

Account type

Account statement

Account balance

Transitive. It is the interpretation that one attribute depends on another, and this one depends on another.
For example:

Fecha_Nacim

Age

Can Drive

Normalization.

The database normalization process consists of applying a series of rules to the

relationships obtained after the transition from the entity-relationship model to the relational model.

Relational databases are normalized for:

Avoid data redundancy.

Avoid data update issues in the tables.

Protect the integrity of the data.

11
In the relational model, it is common to refer to a relation as a table, although for a
a table is considered a relation if it meets certain constraints:

Each column must have its unique name.

There cannot be two identical rows. Duplicates are not allowed.

All data in a column must be of the same type.

We will follow 4 Normal Forms:

First Normal Form.

Search for multivalued fields, meaning that a single field holds two pieces of data.
different, and separates them into distinct fields. For example:
The phone field can be divided into Phone1 and Phone2
According to Normal Form.
Create separate tables for those groups of data that apply to several.
records.
Relate these tables through a foreign key.
Third Normal Form.
Table analysis to distinguish the fields that are not directly associated.
with the primary key.
4. Boyce-Codd Normal Form (BCNF)
The table is divided into two:
CompSales_master y CompVent_Detail
Where the criterion for separating the table is to choose the fields that relate between
if they are multivalued, this mostly occurs in documents such as
sales receipts/invoices/receipts, etc.

Table relationship.

We relate the data in three different ways:

1a1
1avarios
Various

1 to 1
When entering a record in one field, we simultaneously enter one in another.
field (but only one at a time)
1 to various

12
It allows a field to be related, and you can enter several in a field.
records.
Many to many
It establishes that several fields with multiple records can have several associated.
fields also with several records.

13
 Development
The data for the development of the following points were based on the information
previously collected in the company's analysis.

IDENTIFICATION OF ENTITIES

After conducting the preliminary analysis, the following entities are determined:

• Invoice
• Products
• Seller
• Warehouse keeper
• Delivery person
• Clients

LIST OF ENTITIES

We identified how the entities are related.

Emit Seller
Invoice

Receive Describe

Clients Request Product Prepare

Delivery
Wine cellar worker

Delivery person

14
.

Company

Contract

Acquire Product

Employees

Provide Provider
Receive Roll Payment

After establishing the relationship between entities, this will give us the guideline for
define the tables we will use as well as what fields the table will contain.

For example:

We identified the client table and its fields name, surname, type, address, phone.
ID card, RUC, etc....

Then we proceed to carry out the normalization, respectively that is necessary for each
table.

15
NORMALIZATION
First Normal Form

We look for the multivalued fields, and we create a field for each one.

Invoice
Number 1 Employees
Date 12/12/2020 ID card 0104900881
Client juan Name Luis
RUC/CI 0104900881 Last name Perez
Code c001 Address Luis Cordero
Address Bolivar Telefono1 2809090
Telephone 809090 Telephone2 096398610
Seller pedro
gender male
product1 prod1
Fecha_nacim 15/05/1980
product2 prod2
marital status single
Cantidad1 1
[Link] 5 Fecha_ingres 12/11/2009
V. Total2 10 Cargo1 seller
Subtotal 13 Cargo2 cashier
Ivy 1.56 Salary 250
Discount 0 Schedule 1 7:00- 11:30
Total a Pagar 14.56 Schedule2 15:00-23:00

Products
Code p001
Name video
Description Vittorio video Clients
Existence 400 Code C001
entry_date 03-may-09 ID/Ruc 0104900881
date_prepared 24-abr-09 Name Juan
fech_expedicion 05-jul-09 Surname Lopez
Presentation1 500 grams. Direction G. Colombia
Presentation2 200 grams. Phone1 808070
Purchase Price 0.5 Phone2 096398610
Sale Price 0.75 Gender male
Supplier Azuero Aso. Type retailer

16
 Provider
RUC 1658974035698
Name Azuero Aso
Contact Rafael Cuesta
Address Octavio Chacon
Telefono1 808070
Telephone2 096398610
Fax1
Fax2
E-mail1 infAzuer@[Link]
E-mail2 DistAzuer@[Link]
Product_distributionVideo
marca_product Vittorio

Second Normal Form

Multivalued fields must be separated into tables and related to the primary key.

Invoice
Numero_fact 1
Date 12/12/2020
Client juan
RUC/ID 0104900881
Code c001
Address Bolivar
Telephone 809090
Seller Pedro
Amount1 1
Unit Value 5
V. Total2 10
Subtotal 13
Ivy 1.56 Product_Invoice
Discount 0 numero_Fact 1
Total a Pagar 14.56 product name video

17
 Employees
ID card 0104900881
Name Luis
Last name perez
Address Luis Cordero
Telephone 2809090 Cargos_Empleados
Cell phone 096398610 ID Card 010265814 010265814
gender male Cargo seller cashier
Fecha_nacim 15/05/1980
marital status single Employee_Schedules
Fecha_ingres 12/11/2009 ID card 010265814 010265814
Salary 250 schedule 7:00 - 11:30 15:00 - 23:00

Products
Codigo_prod p001
Name noodle
Description of the video Vittorio
Existence 400
fech_ingreso 03-may-09
fech_elaborad April 24, 2009
dispatch_date 05-jul-09
Purchase Price 0.5 Product_Presentation
Selling Price 0.75 product_code001
Provider Azuero Aso. presentation 200g

Client
Code C001
Cedula/Ruc 0104900881
Name juan
Last name Lopez
Direction G. Colombia
Telephone 808070
Cell phone 096398610
Genero male
Type retailer

Provider
RUC 1658974035698
Name Azuero Aso Supplier FAX
Contact Rafael Cuesta RUC 1658974035698
Address Octavio Chacon Fax
Telephone 808070
Cell phone 096398610 E-MAIL_Proveedor
Product_distNoodle RUC 1658974035698
brand_productVittorio e-mail infAzuer@[Link]

18
It was not necessary to separate the phones into a table, just separated into two fields and the
let's rename landline and mobile phone

Third Normal Form

Remove the data not dependent on the key

Invoice Product_Invoice
Numero_fact 1 numero_Fact 1
Client john nom_product video
RUC/ID 0104900881
Code c001 Fecha_Factura
Address Bolivar date_code I001
Phone 809090 date 12-may-09
Seller peter
Cantidad1 1 Tax Invoice
[Link] 5 codigo_impuesto Im001
V. Total2 10 value 1.56
Subtotal 13
Total a Pagar 14,56 Invoice_Discounts
discount_code_dsc001
0 0.00

Employees
Identity card 0104900881
Name Luis Employee_positions
Last name perez Codigo_cargos Carg001 Carg002
Address Luis Cordero Cargo seller cashier
Phone 2809090
Cellular 096398610 Employee_Schedules
gender male schedule_code_hour001 hor002
Fecha_nacim 15/05/1980 schedule 7:00 - 11:30 15:00 - 23:00
marital status single
Fecha_ingres 12/11/2009 Sueldo_Empleados
Cod_Cargos 250 Schedule Code hor001 hor002
Code_Schedules 250 Amount 250 300
Salary_code 250 Description warehouse seller

19
 Products
Codigo_prod p001 Product Presentation
Name video codigo_presp001
Description Vittorio video 200g presentation.
Existence 400
fech_ingreso 03-may-09 Product Entry Date
date_prepared 24-abr-09 code_entryI001
fech_expedicion 05-jul-09 date 12-may-09
Precio Compra 0.5
Selling Price 0.75
Provider Azuero Aso.
presentation_code p001
codigo_ingreso I001

Providers Supplier FAX

RUC 1658974035698 RUC 1658974035698
Name Azuero Aso Fax
Contact Rafael Cuesta
Address Octavio Chacon E-MAIL_Proveedor
Phone 808070 RUC 1658974035698
Cell phone 096398610 email infAzuer@[Link]
Product distributionVideo
product_brand Vittorio Product_Distribution_Provider
cod_prod p_dist001 cod_prod p_dist001
description noodle

Fourth Normal Form

Not all tables reach these instances or others later, some may only reach the
first or second.

INVOICE_Master INVOICE_Client FACTURA_Detalle

Numero_fact 1 client_code 1 Numero_factu 1
date_code RUC/CI 1 Quantity Juan
client_code juan Client 5 [Link] 1
prod_cod 1 Telephone [Link] 5
tax_code 5
codigo_desc dsc001
Subtotal 13 Producto_Factura Tax Invoice
Total a Pagar 14.56 prod_cod 1 impueIm001_code
product_video_name value 1.56

Fecha_Factura Invoice Discounts

code_dateI001 code_descudsc001
date 12-may-09 0 0,00

20
TABLE DESCRIPTION
CONSTRAINS, TIPOS DATOS, LONGITUD
Luego de llevar a cabo la normalización ya tenemos definida la estructura de las mismas, el
The next step will be to define what type of data will be stored in its fields, and how much.
it will store, also if any field will serve as a link with another table that is to say if it is a key

Master_invoice
constrain field data type length
NN FK date_code char 4
PK NN invoice number int 4
NN FK product_code char 4
NN FK codigo_impuesto char 4 Invoice_Detail
NN FK discount_codechar 4 constraint field data type length
NN FK client_code char 4 PK NN invoice number 4
NN subtotal real (5,2) NN FK amount int 3
NN Total a Pagar real (5,2) NN FK unit price real (5,2)
NN FK employee_id 10 NN FK v. total real (5,2)
NN character state 8 NN FK production_code char 4

Tax invoice Discount invoice

constrain field data type length constrain field data type length
PK NN impeachment_code 4 PK NN codigo_descuento char 4
NN FK value real 2 NN FK value real 2

Customer_invoice
constrain field data typelength
PK NN client_code char 4
FK RUC/ID char 13

EMPLOYEES
client constrain field data type length
constrain field data type length PK NN cedula_empleado char 10
PK NN client_code char 4 NN name character 30
FK RUC/CI character 13 NN last name character 30
NN name character 25 NN FK address character 50
NN FK surname character 25 NN telephone character 9
Direction character 50 NN cell phone character 9
telephone character 9 NN gender char 7
cell phone character 9 NN fecha_nacim date
gender character 7 NN estado_civil date
NN type character 8 NN fecha_ingreso date

Empleados_sueldo Employees_position
constrain field data typelength constrain field data type length
NN employee ID 10 NN employment_card 10
PK NN codigo_sueldochar 4 PK NN cargo_code 4

21
 Empleados_horarios salaries
constrain field data type length
constrain data type fieldlength
PK NN codigo_sueldochar 10
NN employer card 10 NN character description 25
PK NN schedule_code char 4 salary real (5,2)

schedules charges
constrain field data type length constrain field data type length
PK NN schedule_code char 4 PK NN codigo_cargo char 4
NN schedule char 13 NN cargo character 15

Products
constrain field data type length
PK NN product_code char 4
Supplier
FK nombre character 20
field constraint data type length
NN description char 60
PK NN Name character 30
NN FK existence char 25
NN fecha_ingreso date FK Contact char 60
NN fecha_elaborado date NN Direction character 50
NN fecha_expedicion date NN FK Phone character 9
NN precio_compra real (5,2) NN Cell phone character 9
NN precio_venta real (5,2) NN RUC_supplier 13
NN Supplier RUC char 13 NN fax_code char 4
presentation_code 4 NN email_code char 4

Product presentation Supplier FAX

constrain field data type length constraint field data type length
NN char presentation 25 fax character 9
PK NN presenchar_code 4 PK NN fax_code char 4

E-mail_Proveedor
constrain field data type length
email character 30
PK NN email_code char 4

22
Relational Model

23
CONCLUSIONS
After the development of this project, and based on the data acquired and the practice carried out, we have
reached the following conclusion:

The development of a good Database depends solely on how it

is designed, for which we need to follow the essential steps that are given to us
they present since the rest will depend on the type of database, or for what
the Database will be applied, but by following the steps we can improve the
stability and query speed of the Database, but also this
it will depend on the Database engine

24
Recommendations
After developing this document and experiencing the base design of
From the data, we can give the following recommendation:

That the development of the Database is worked on gradually.

with real data and examples as this will give us a better perspective for the
toma de decisiones y saber si es oportuno aplicar algún método.

25
GLOSSARY
Rule = table or file

Tuple = record, row or line

Attribute = column or field

Key = key or identification code

Candidate Key = minimal superkey

•Clave Primaria= clave candidata elegida

Foreign Key = external key or foreign key

•Clave Alternativa= clave secundaria

•Dependencia Multivaluada= dependencia multivalor

RDBMS = From English Relational Data Base Manager System which means, System
Relational Database Manager.

1NF means First Normal Form.

DBMS: Data Base Management System.
It consists of a database and a set of applications (programs) to
to have access to them.

• Data Model.- is a set of conceptual tools for describing the

data, the relationships between them, their semantics and their limitations.

• Redundancy.- This occurs when data is unnecessarily repeated in the

files that make up the database.

• Inconsistency.-It occurs when there is contradictory or incongruent information.

in the database.

26
BIBLIOGRAPHY

Data taken and references from:

[Link]

[Link]/~mmarques/f47/apun/[Link].
[Link]
http:/ /[Link]/articulos/[Link]

[Link]
[Link]/[Link]

27
Designer captures and database in Access, SQL

CASE STUDIO Designer

Implanted in Access

28
Implanted in SQL

29