Base de Datos FINAL

FACULTAD DE INGENIERÍA
CARRERA “INGENIERÍA EMPRESARIAL”
“DISEÑO E IMPLEMENTACIÓN DE BASE DE DATOS PARA LA
EMPRESA BAMBINO PIZZA”
Gestión de Base de Datos
Estudiantes:
César Augusto Díaz Camacho
Héctor Martin Aguilar López
Rodríguez Quiliche, Roberto Carlos
Camacho Alva Violeta Lidiel
Docente:
Ing. Paul Omar Cueva Araujo
Cajamarca – Perú
RESUMEN
El objetivo de la presente investigación es ordenar y mejorar el sistema interno y estructural

de la empresa” Bambino Pizza” a través de una base de datos completa y simple; para la
cual se utilizó la metodología estándar de diseño de base de datos que tiene distintas etapas
de especificación y requisitos, diagrama Entidad-Relación, restricciones, esquema relacional
y normalización, además de las técnicas de desarrollo de Sistemas de Información.
ABSTRAC
The objective of this research is to order and improve the internal and structural system of
the company "Bambino Pizza" through a complete and simple database; for which the
standard database design methodology was used, which has different stages of specification
and requirements, Entity-Relationship diagram, restrictions, relational schema and
normalization, in addition to Information Systems development techniques.
INDICE DE CONTENIDO
RESUMEN.................................................................................................................................................................................2
INDICE DE TABLAS..............................................................................................................................................................4
INDICE DE ILUSTRACIONES.............................................................................................................................................6
I. INTRODUCCION...........................................................................................................................................................7
II. OBJETIVOS....................................................................................................................................................................8
a. Objetivos generales:....................................................................................................................................................8
b. Objetivos específicos:..................................................................................................................................................8
III. MARCO TEORICO...................................................................................................................................................9
 Base de Datos:.............................................................................................................................................................9
 SGBD:..........................................................................................................................................................................9
 Tabla:...........................................................................................................................................................................9
 Columna:.....................................................................................................................................................................9
 Fila:.............................................................................................................................................................................10
 Cardinalidad:............................................................................................................................................................10
 Normalización:..........................................................................................................................................................10
 1FN:............................................................................................................................................................................10
 2FN:............................................................................................................................................................................11
 3FN:............................................................................................................................................................................11
 Modelo Conceptual:..................................................................................................................................................11
 Diagrama Entidad-Relacion:...................................................................................................................................11
 Entidad:.....................................................................................................................................................................11
 Relacion:....................................................................................................................................................................12
 Esquema Relacional:................................................................................................................................................12
IV. DESCRIPCION DEL CASO DE ESTUDIO..........................................................................................................13
1. Datos completos de la empresa................................................................................................................................13
a. Nombre de la empresa:........................................................................................................................................13
b. Misión:...................................................................................................................................................................13
c. Visión:....................................................................................................................................................................13
d. Principales procesos:............................................................................................................................................13
e. Historia:.................................................................................................................................................................14
f. Rubro:....................................................................................................................................................................14
h. Número de empleados..........................................................................................................................................14
i. Servicios.................................................................................................................................................................14
2. Realidad problemática..............................................................................................................................................15
3. Restricciones..............................................................................................................................................................16
4. Modelo Entidad Relación.........................................................................................................................................16
5. Modelo Relacional.....................................................................................................................................................18
6. Normalización del esquema relacional....................................................................................................................20
V. REFERENCIAS BIBLIOGRAFICAS........................................................................................................................22
INDICE DE TABLAS
INDICE DE ILUSTRACIONES
Ilustración 1: Diagrama de procesos operativos.................................................................................................12
Ilustración 2: Modelo entidad-relación..............................................................................................................16
I. Introducción
Bambino Pizza es una pizzería orgullosa de ser cajamarquina, con el mejor

ambiente. Cada día la empresa busca brindar un excelente servicio, manteniendo
clientes satisfechos y convirtiéndolos en nuestro mejor medio de promoción. se
distingue de las demás pizzerías por poseer un ambiente singular donde se come las
mejores pizzas, acompañado de buenos amigos y familiares, creando un buen
recuerdo.
El presente trabajo se enfoca en evaluar la factibilidad y aceptación de una nueva
franquicia como proyecto de inversión en la ciudad de Cajamarca
II. Objetivos
a) Objetivo General
- Ordenar y mejorar el sistema interno y estructural de la empresa ·”Bambino pizza” a

través de una base de datos completa y simple. En el área de suministro de proveedor
y horario de atención utilizando nuestro gestor de base de datos SQL Server
Management 2014 para crear nuestra base de datos de una manera correcta.
b) Objetivo Especifico
- Aplicar la enseñanza que nos ha brindado nuestro profesor en clase.
- En caso de que haya alguna pérdida de información de la empresa tener el

convencimiento de que se va a lograr recuperar gracias a la base de datos empleada.
- Implementar la base de datos para esta determinada empresa en un sistema gestor de
base de datos.
III. Marco Teórico

i. Base de Datos
Desde el punto de vista informático, la base de datos es un sistema formado por un conjunto de datos
almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese
conjunto de datos. (Maestros del Web, 2018)
Una base de datos es un conjunto de archivos dedicados a guardar información relacionada entre sí,
con referencia entre ellos de manera que se complementen y con la posibilidad de relacionarlos en
base a diferentes criterios. (Aguilar,2006,p.17)
Una base de datos es un conjunto de datos estructurado. El grado de estructuración depende del
formato de la base de datos. Por lo tanto, dependiendo de las circunstancias, también puede usarse
un archivo de texto sencillo como base de datos. Esto sería útil principalmente para datos
estructurados de un modo sencillo. (Programación de Bases de Datos con MYSQL y PHP).
ii. SGBD
Un sistema gestor de base de datos es un conjunto de programas que permiten el almacenamiento,

modificación y extracción de la información en una base de datos. Los usuarios pueden acceder a la
información usando herramientas específicas de consulta y de generación de informes, o bien
mediante aplicaciones al efecto. (Wikipedia).
Un Sistema de Gestión de Bases de Datos consiste en una colección de datos interrelacionados y un

conjunto de programas para acceder a los mismos, es un conjunto de programas el cual su principal
funcionalidad es la privacidad, la integridad y la seguridad de los datos.
El SGBD debe proporcionar un sistema que permita explorar las bases de datos y sus
características. Un SGBD se compone de bases de datos que, a su vez, tienen tablas con columnas.
Si el SGBD no contara con un sistema para explorar la lista de elementos, solo la persona que creo
la base de datos conocería sus características. (Acceso a datos en aplicaciones web del entorno
servidor. IFCD0210).
iii. Tabla
Las tablas son objetos de base de datos que contienen todos sus datos. En las tablas, los datos se
organizan con arreglo a un formato de filas y columnas, similar al de una hoja de cálculo (según
“docs.microsoft”).
Tras diseñar una base de datos, podrá crear las tablas que almacenaran los datos en la base de
datos. Normalmente, los datos se almacenan en tablas permanentes; no obstante, también se
pueden crear tablas temporales. Las tablas se almacenan en los archivos de base de datos hasta
que se eliminan, y están disponibles para cualquier usuario que cuente con los permisos
necesarios. (Microsoft SQL Server 2008 R2. Motor de base de datos y administración).
Es una herramienta donde los datos los organizamos en filas y columnas, lo utilizaremos para
ordenar datos de nuestra empresa.
iv. Columna
El término campo es incorrectamente intercambiado con el de columna, el término correcto a

usar es el de Columna Ejemplo de tabla: Nombre Dirección 1 Dirección 2 separada de ciudades,
de la que cualquier información del estado o del país puede ser tomada) Código postal Industria
etc. (Wikipedia).
Toma los valores de una sola columna en todas las filas seleccionadas de una tabla o mensaje y
devuelve un resultado individual escalar. (Microsoft SQL Server 2008 R2. Motor de base de
datos y administración).
Una columna nos sirve para organizarnos, siguiendo un orden correcto, podemos actualizarlo
cuando queramos.
v. Fila
En informática, o concretamente en el contexto de una base de datos relacional, un registro (también

llamado fila) representa un objeto único de datos implícitamente estructurados en una tabla. En
términos simples, una tabla de una base de datos puede imaginarse formada de filas y columnas o
campos. (Wikipedia).
Representa un objeto único de datos implícitamente estructurados en una tabla. En términos simples,
una tabla de una base de datos puede imaginarse formada de filas y columnas o campos. Cada fila de
una tabla representa un conjunto de datos relacionados, y todas las filas de la misma tabla tienen la
misma estructura. (Base de datos, Vicenta Pérez Fernández y coautores).
Una fila son datos de una misma empresa o tipo que podemos organizarlo con la misma estructura y
cada fila estará relacionada a otra).
vi. Cardinalidad
Es Simplemente la forma en que se relacionan las Entidades, o expresa cuantas entidades se

relacionan con otras entidades. Hay varias maneras de mostrar las cardinalidades.
(basededatosaplicado.blogspot.com).
Llamaremos cardinalidad al número de filas que se emparejan con una dada. Nos interesa
representar en el diagrama las cardinalidades. (Bases de datos relacionales por Enrique Rivero
Cornelio).
Cardinalidad nos indica el número de entidades con las que puede estar relacionada otra entidad
dada, pueden ser de uno a uno, de uno a varios, etc.
vii. Normalización
Es el proceso de organizar los datos de una base de datos, valga la redundancia. Debemos tener en
cuenta la creación de tablas y las reglas que se usan para definir las relaciones, estas reglas son
diseñadas para proteger los datos, y para que la base de datos sea flexible con el fin de eliminar
redundancias y dependencias incoherentes. (ed.team/blog/normalizacion-de-bases-de-datos).
La normalización es un concepto que hace referencia a las relaciones. Básicamente, el principio de

normalización indica que las tablas de las bases de datos eliminaran las incoherencias y
redundancias, y minimizaran la eficacia. (Base de datos relacionales por Fray León Osorio).
Normalización hace referencia a organizar datos de una base de datos. Normalizando haremos que
nuestras tablas nos muestren solo lo necesario.
viii. 1FN
Todos los atributos son «atómicos», La tabla contiene una clave primaria única, La clave primaria
no contiene atributos nulos, No debe existir variación en el número de columnas, Los campos no
clave deben identificarse por la clave, Debe Existir una independencia del orden tanto de las filas
como de las columnas. ( El Blog de 19E37).
Cumple el requisito de la Primera Forma Normal (1NF) de sólo tener campos atómicos, no contener
atributos nulos. (Base de datos Jonathan de la Torre, 2012).
La primera forma normal veremos si cumple o no sus requisitos, si cumple que tiene campos
atómicos, y no atributos nulos entonces si cumpliría 1FN.
ix. 2FN
Una tabla está en 2FN si además de estar en 1FN cumple que los atributos no clave depende de
TODA la clave principal. ( El Blog de 19E37).
La regla de la Segunda Forma Normal (2FN) establece que todas las dependencias parciales se
deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que
describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. (Base de datos
Jonathan de la Torre, 2012).
Nuestra tabla ya estaría en 1FN, ahora, debe de cumplir también que los atributos no clave depende
de toda la clave principal.
x. 3FN
Una tabla está en 3FN si además de estar en 2FN no existe ninguna dependencia transitiva entre los
atributos que no son clave. ( El Blog de 19E37)
La Tercera Forma Normal (3NF) la relación debe estar en 2NF y además los atributos no clave
deben ser mutuamente independientes y dependientes por completo de la clave primaria. También
recordemos que dijimos que esto significa que las columnas en la tabla deben contener solamente
información sobre la entidad definida por la clave primaria y, por tanto, las columnas en la tabla
deben contener datos acerca de una sola cosa. (Base de datos Jonathan de la Torre, 2012).
Una tabla ya debería estar en 2Fn y además cumplir que los atributos no clave deben ser
mutuamente independientes y dependientes por de la clave primaria.
xi. Modelo Conceptual
Un modelo conceptual de datos identifica las relaciones de más alto nivel entre las diferentes
entidades. Las características del modelo conceptual de datos incluyen:
Incluye las entidades importantes y las relaciones entre ellas.
No se especifica ningún atributo.
No se especifica ninguna clave principal. (www.tecnologias-informacion.com/).
Consiste en organizar un esquema teórico de los datos, ya que será necesario para poder pasarlo de
la forma real a la forma correcta para un sistema informático. Esta información será almacenada y
gestionada por un sistema gestor de base de datos. En este modelo encontraremos distintos modos
de utilizarlo como el modelo entidad relación. (PHP y MySQL: Tecnología para el desarrollo de
aplicaciones web).
El objetivo de hacer un modelo conceptual es construir dicho modelo de acuerdo con todos los
requisitos de datos de organización enteramente independiente de los detalles de implementación y
esto nos servirá de base para las etapas que aún faltan.
xii. Diagrama Entidad-Relación
Es un tipo de diagrama de flujo que ilustra cómo las "entidades", como personas, objetos o
conceptos, se relacionan entre sí dentro de un sistema. Los diagramas ER se usan a menudo para
diseñar o depurar bases de datos relacionales en los campos de ingeniería de software, sistemas de
información empresarial, educación e investigación. (www.lucidchart.com)
Los diseños de bases de datos suelen apoyarse en diagramas a través de los cuales se tratan de
visualizar las diferentes entidades que intervienen, las relaciones entre ellas y el tipo de estas
relaciones. Estos gráficos son de ayuda para decidir las distintas tablas que deben ser utilizadas en
la base de datos. ( PHP y MySQL: Tecnología para el desarrollo de aplicaciones web).
Diagrama entidad relación hace referencia a un sistema que ilustra las entidades relacionadas entre
sí.
xiii. Entidad
Objeto exclusivo único en el mundo real que se está controlando. Algunos ejemplos de entidad son
una sola persona, un solo producto o una sola organización.(
www.ibm.com/support/knowledgecenter/es/SSWSR9_11.6.0/com.ibm.mdmhs.overview.doc )
Es un objeto que existe y puede distinguirse de otros objetos. Pueden ser de dos tipos, concretas y
abstractas. (Base de datos relacionadas,)
Entidad son objetos dentro de la base de datos ya sea de una persona, producto, organización, etc.
xiv. Relación
Una relación funciona haciendo coincidir datos en columnas de clave, normalmente columnas (o
campos) que tienen el mismo nombre en ambas tablas. En la mayoría de los casos, la relación
conecta la clave principal, o la columna de identificador único para cada fila, de una tabla a un
campo de otra tabla. (https://docs.microsoft.com/).
Una relación es una asociación entre varias entidades. Por ejemplo, se puede definir una relación
que asocie al alumno “ANA MARIA MUÑOZ” con el programa ingernieria civil, lo cual indicaría
que la alumna esta matriculada en ese programa. Llamariamos al conjunto de tales relaciones
Alumna programa. (Base de datos relacionales)
Una relación hace referencia a datos en cada columna, o columnas que tengan el mismo nombre en
ambas tablas.
xv. Esquema Relaciona
Se rige por algunas normas sencillas: Todos los datos se representan en forma de tablas (también
llamadas “relaciones”). Incluso los resultados de consultar otras tablas. La tabla es además la
unidad de almacenamiento principal. (www.campusmvp.es)
En el modelo relacional se basa en el concepto matemático de relación. En este modelo, la

información se representa en forma de tablas o relaciones, donde cada fila de la tabla se interpreta
como una relación ordenada de valores (un conjunto de valores relacionados entre sí). (Solo es
ciencia, por Armando Cifuentes Gonzales 2017).
El esquema relacional se refiere a tablas o relaciones que son ordenadas entre sí.
xvi. Diseño Lógico de Base de Datos
A partir del esquema conceptual, y teniendo en cuenta los requisitos de proceso y de entorno, se
elabora un esquema lógico estándar (ELS), que se apoya en un modelo lógico estándar (MLS), que
será el mismo modelo de datos soportado por el SGBD que se vaya a utilizar, pero sin las
restricciones ligadas a ningún producto comercial. [ CITATION Fra01 \l 3082 ].
Diseño lógico, cuyo objetivo es transformar el diseño conceptual obtenido y adaptarlo al modelo de
datos en el que se apoya el SGBD que se va a utilizar. En nuestro caso, el SGBD es relacional, por
lo cual nos referiremos a este modelo de datos.[ CITATION Jos10 \l 3082 ].
Diseño lógico hace referencia a una descripción que cada uno hace en su base de datos y que esta
misma será ejecutada en un SGBD.
xvii. Tipos de datos (SQL)
Cuando definimos una tabla, variable o constante debemos asignar un tipo de dato que indica los
posibles valores. El tipo de datos define el formato de almacenamiento, espacio que de disco-
memoria que va a ocupar un campo o variable, restricciones y rango de valores válidos. [ CITATION
Mik06 \l 3082 ].
Un tipo de datos define qué tipo de valor puede contener una columna: datos enteros, datos de
caracteres, datos monetarios, datos de fecha y hora, cadenas binarias, etc.[ CITATION Ric06 \l 3082 ]
En base de datos existen variedad de tipos de datos, los cuales hemos ido aprendiendo a utilizarlos
dentro de SQL.
xviii. Diseño Físico de Base de Datos
El diseño físico de la base de datos optimiza el rendimiento a la vez que asegura la integridad de los
datos al evitar repeticiones innecesarias de datos. Durante el diseño físico, se transforman las
entidades en tablas, las instancias en filas y los atributos en columnas[ CITATION Jor12 \l 3082 ].
Etapa del diseño de una base de datos que transforma la estructura obtenida en la etapa del diseño
lógico con el objetivo de conseguir una mayor eficiencia y que, además, la completa con aspectos
de implementación física que dependerán del SGBD que se debe utilizar [ CITATION Raf05 \l
3082 ].
El diseño físico ya es lo último para hacer un diseño de base de datos aquí probaremos que todo se
ejecute y hacer que las tablas se transformen en tablas, atributos en columnas, etc.
xix. SQL
El lenguaje estructurado de consultas (SQL, Structured Query Language) apoya la creación y

mantenimiento de la base de datos relacional y la gestión de los datos dentro de la base de datos
[ CITATION And10 \l 3082 ].
SQL es un lenguaje de dominio específico utilizado en programación, diseñado para administrar, y

recuperar información de sistemas de gestión de bases de datos relacionales. Una de sus principales
características es el manejo del álgebra y el cálculo relacional para efectuar consultas con el fin de
recuperar, de forma sencilla, información de bases de datos, así como realizar cambios en ellas.
SQL es un programa que nos ayuda a recopilar información y almacenarla ordenadamente que nos
servirá de mucho para cualquier tipo de empresa.
xx. DDL
Las instrucciones DDL se usan para crear, modificar o borrar objetos en una base de datos como
tablas, vistas, esquemas, dominios, activadores, y almacenar procedimientos. Las palabras clave en
SQL más frecuentemente asociadas con las instrucciones DDL son CREATE, ALTER y DROP.
Por ejemplo, se usa la instrucción CREATE TABLE para crear una tabla, la instrucción ALTER
TABLE para modificar las características de una tabla, y la instrucción DROP TABLE para borrar
la definición de la tabla de la base de datos [ CITATION Rob11 \l 3082 ].
Proporciona órdenes para definir, modificar o eliminar los distintos objetos de la base de datos
(tablas, vistas, índices…). (Gestión base de datos, Sphinx).
Data Definition Language ayuda a un sistea gestor de base de datos a definir estructuras que
almacenan datos.
xxi. DML
Las instrucciones DML se usan para recuperar, agregar, modificar o borrar datos almacenados en
los objetos de una base de datos. Las palabras clave asociadas con las instrucciones DML son
SELECT, INSERT, UPDATE y DELETE, las cuales representan los tipos de instrucciones que
probablemente son más usadas. Por ejemplo, puede usar la instrucción SELECT para recuperar
datos de una tabla y la instrucción INSERT para agregar datos a una tabla [ CITATION And10 \l
3082 ].
El DML (Data Manipulation Language) lo forman las instrucciones capaces de modificar los datos
de las tablas. Al conjunto de instrucciones DML que se ejecutan consecutivamente, se las llama
transacciones y se pueden anular todas ellas o aceptar, ya que una instrucción DML no es realmente
efectuada hasta que no se acepta (COMMIT) [ CITATION And10 \l 3082 ].
DML ayuda y es importante porque inserta, suprime y modifica filas de tablas.
xxii. DQL
Las declaraciones DML se utilizan para realizar consultas sobre los datos dentro de los objetos de
esquema. El propósito del comando DQL es obtener alguna relación de esquema basada en la
consulta que se le pasa [ CITATION Rob11 \l 3082 ].
Los comandos de SQL que se utilizan para recuperar datos de la base de datos se denominan
colectivamente como DQL. Así que todas las sentencias Select se encuentran bajo DQL.
[ CITATION Raf05 \l 3082 ].
DDL permite administrar, otorgar y denegar permisos que son determinado en distintas tareas.
xxiii. Restricciones en Base de Datos
Una restricción consiste en la definición de una característica adicional que tiene una columna o
una combinación de columnas, suelen ser características como valores no nulos (campo requerido),
definición de índice sin duplicados, definición de clave principal y definición de clave foránea
(clave ajena o externa, campo que sirve para relacionar dos tablas entre sí) [ CITATION Raf05 \l
3082 ].
Las restricciones en SQL Server son reglas y restricciones predefinidas que se aplican en una sola
columna o en varias columnas, relacionados a los valores permitidos en las columnas, para
mantener la integridad, precisión y confiabilidad de los datos de esa columna. En otras palabras, si
los datos insertados cumplen con la regla de restricción, se insertarán con éxito. Si los datos
insertados violan la restricción definida, la operación de inserción se cancelará [ CITATION
Ahm10 \l 3082 ].
Las restricciones de base de datos están dadas para cumplir y conociéndolas podemos cumplir con
ellas al momento de hacer nuestra base de datos.
xxiv. SQL Server
Microsoft SQL Server es un sistema de gestión de base de datos relacional (RDBMS) producido
por Microsoft. Su principal lenguaje de consulta es Transact-SQL, una aplicación de las normas
ANSI / ISO estándar Structured Query Language (SQL) utilizado por ambas Microsoft y Sybase
[ CITATION Jos05 \l 3082 ].
Es un sistema para la gestión de base de datos producidos por Microsoft basado en el modelo
relacional. Ofrece a los desarrolladores de base de datos un soporte potente de transacciones.
Permite la administración de información de otros servidores de datos y no necesariamente del
mismo sistema operativo, etc [ CITATION Tor12 \l 3082 ].
SQL Server es un sistema de gestión de base de datos producidos por Microsoft basado en modelo
relacional.
xxv. Transact SQL

Transact SQL es el lenguaje de programación que proporciona SQL Server para ampliar SQL con
los elementos característicos de los lenguajes de programación: variables, sentencias de control de
flujo, bucles [ CITATION Lui09 \l 3082 ]
Transact SQL es el lenguaje de programación que proporciona SQL Server para extender el SQL
estándar con otro tipo de instrucciones, para darle las características de un lenguaje de
programación. [ CITATION Lui09 \l 3082 ]
Transact SQL se utiliza para realizar búsquedas, cambiar y definir una base de datos.
xxvi. Consultas (Base de Datos)
Se utilizan para crear, alterar y eliminar y eliminar tablas, y para crear y eliminar índices. Las
consultas en realidad son instrucciones SQL que se crea cuando diseña una consulta usando la
cuadricula de diseño en la ventana consulta[ CITATION Mar06 \l 3082 ].
Las consultas toman la forma de un lenguaje de comandos que permite seleccionar, insertar,
actualizar, averiguar la ubicación de los datos, y más. También hay una interfaz de programación
Consulta se refiere a cuando queremos saber algo en específico y aplicando los comandos que nos
han enseñado podemos buscar seleccionadamente lo que necesitemos.
xxvii. Subconsultas (Base de Datos)
Las subconsultas, al igual que las operaciones join, proporcionan una forma de acceder a datos en
múltiples tablas con una sola consulta. Una subconsulta puede agregarse a una instrucción
SELECT, INSERT, UPDATE o DELETE para permitir a esa instrucción utilizar los resultados de
la consulta arrojados por la subconsulta [ CITATION Jor12 \l 3082 ].
Una subconsulta tiene la misma sintaxis que una sentencia SELECT normal exceptuando que
aparece encerrada entre paréntesis, no puede contener la cláusula ORDER BY, ni puede ser la
UNION de varias sentencias SELECT, además tiene algunas restricciones en cuanto a número de
columnas según el lugar donde aparece en la consulta principal [ CITATION Tor12 \l 3082 ].
Una sub consulta está dentro de una consulta, es decir haremos una consulta dentro de otra.
xxviii. Algebra relacional
Las operaciones de álgebra relacional manipulan relaciones. Esto significa que estas
operaciones usan una o dos relaciones existentes para crear una nueva relación. Esta nueva
relación puede entonces usarse como entrada para una nueva operación.[ CITATION Jos10 \l 3082 ].
Para especificar una consulta en álgebra relacional, es preciso definir uno o más pasos que sirven
para ir construyendo, mediante operaciones de álgebra relacional, una nueva relación que contenga
los datos que responden a la consulta a partir de las relaciones almacenadas. Los lenguajes basados
en el álgebra relacional son procedimentales, dado que los pasos que forman la consulta describen
un procedimiento. [ CITATION Raf05 \l 3082 ].
El álgebra relacional es un conjunto de operaciones que describen paso a paso cómo computar una
respuesta sobre las relaciones, tal y como éstas son definidas en el modelo relacional.
xxix. Vistas (Base de datos)
Una vista materializada es un objeto de la base de datos almacenado en el dispositivo de

almacenamiento no volátil que contiene el resultado de una consulta pre calculada. Las vistas
materializadas permiten un acceso más eficiente a los datos a cambio de incrementar el tamaño de
la base de datos.[ CITATION And10 \l 3082 ].
Relación que se construye a partir de una sola instrucción SQL SELECT. Las vistas SQL tienen
cuando mucho una trayectoria de valores múltiples. En la mayoría de los productos DBMS, incluido
Acces, Oracle y el servidor SQL, el termino vista significa vista SQL. (Procesamiento de bases de
datos: fundamentos, diseño e implementación)[ CITATION Jor12 \l 3082 ]
En vistas almacenamos una definición, es presentada en forma de una tabla a partir de varias tablas
que forman conjunto en una base de datos.
xxx. Combinaciones (Base de Datos)
La combinación consigue crear una sola tabla a partir de las tablas especificadas en la cláusula
FROM, haciendo coincidir los valores de las columnas relacionadas de estas tablas. [ CITATION
Raf05 \l 3082 ].
Esta acción se realiza por medio de la cláusula JOIN la cual “combinar dos o más relaciones según
una condición para obtener tuplas compuestas por atributos de las dos relaciones combinadas”
(PostgreSQL) [ CITATION Pao17 \l 3082 ]
Las combinaciones permiten recuperar datos de dos o más tablas según las relaciones lógicas entre
ellas. Las combinaciones indican cómo debe usar SQL Server los datos de una tabla para
seleccionar las filas de otra tabla.
xxxi. Procedimientos almacenados (Stored Procedures)
Un procedimiento almacenado de SQL Server es un grupo de una o varias instrucciones Transact-

SQL o una referencia a un método de Common Runtime Language (CLR) de Microsoft .NET
Framework [ CITATION Mik06 \l 3082 ]
Los procedimientos almacenados son módulos o rutinas que encapsulan código para su
reutilización. Un procedimiento almacenado puede incluir parámetros de entrada, devolver
resultados tabulares o escalares y mensajes para el cliente, invocar instrucciones de lenguaje de
definición de datos (DDL) e instrucciones de lenguaje de manipulación de datos (DML), así como
devolver parámetros de salida. En SQL Server 2008 existen dos tipos de procedimientos
almacenados: Transact-SQL o CLR.[ CITATION Mar06 \l 3082 ]
Un procedimiento almacenado es un programa almacenado físicamente en una base de datos. Su

implementación varía de un gestor de bases de datos a otro. La ventaja de un procedimiento
almacenado es que al ser ejecutado, en respuesta a una petición de usuario, es ejecutado
directamente en el motor de bases de datos, el cual usualmente corre en un servidor separado.
IV. Descripcion del caso de estudio
a. Datos Completos de la Empresa
 Misión
Trabajamos para que nuestros clientes tengan una experiencia de compra inolvidables que
sobrepasan sus expectativas, a través de la innovación y servicio diferenciado; apoyado por
el trabajo en equipo, la constante capacitación y el uso responsable de los recursos.
 Visión
Ser reconocidos como la organización operadora de restaurantes más confiable y

comprometida a nivel internacional, ofreciendo productos y un servicio de calidad superior.
 Principales Procesos:
Bambino pizza se especializa por la preparación de:
- Pizzas
- Pastas
 Historia
“Bambino Pizza” inicia sus actividades en agosto del 2017, por iniciativa de un
emprendedor cajamarquino, que decide abrir su propio negocio, previamente al trabajar en
otras pizzerías; el decide apostar por su propio negocio tratando de mejorar el servicio para
marcar la diferencia de calidad dentro de este rubro.
 Rubro: Restaurantes-Alimentos
 Datos Importantes de la empresa:
Ruc: 20602356354
Razón Social: BAMBINO PIZZA E.I.R.L
Dirección: JR. SILVA SANTISTEBAN NRO. 141
Ciudad: Cajamarca-Cajamarca
b. Realidad Problemática
La empresa Bambino’s pizza quiere incorporar una base de datos para almacenar los datos de clientes ( DNI
del cliente, nombre, Apellidos, celular, dirección), empleados (DNI del empleado, Apellidos,
celular, dirección), pedido (ID de pedido Fecha de pedido) contiene (DNI de empleado DNI de
cliente) producto (id de producto, categoría, ruc de proveedor precio insumo) proveedor (ruc
de proveedor nombre de encargado, nombre de la empresa, teléfono, dirección, ciudad) un
empleado puede atender varios pedidos , pero un pedido puede ser atendido por un empleado ,
un cliente puede realizar varios pedidos pero un pedido puede ser realizado por un solo
cliente , un pedido puede contener varios productos y un producto puede estar contenido en
varios pedidos, un producto puede ser suministrado varios proveedores y un proveedor puede
suministrar varios productos
c. Restricciones.
TABLAS ATRIBUTOS (RESTRICCIONES)

DNI_Cliente (Clave primaria)
Nombre (No nulo)
Cliente Apellidos (No nulo)
Celular (nulo)
CHECK (Celular LIKE ‘[ 9 ] %’)), quiere
decir que todo los números de celular
de los clientes debe empezar con 9,
dirección opcional,
Contiene ID_pedido (INT IDENTITY, es decir el
código de platillo se genera
automáticamente) (Clave primaria)
id_producto (no nulo)
DNI_empleado llave primaria,
nombre (no nulo),
Empleado Apellido (no nulo),
Celular (nulo)
CHECK (Celular LIKE ‘[ 9 ] %’)), quiere
decir que todo los números de celular
de los clientes debe empezar con 9,
dirección (nulo),
ID_pedido (INT IDENTITY, es decir el
código de pedido se genera
Pedido automáticamente) (Clave primaria)
Fecha_pedido DATE DEFAULT GETDATE(),
DNI_empleado no nulo,
DNI_cliente no nulo
id_producto (INT IDENTITY, es decir

el código de producto se genera
Producto automáticamente) (Clave primaria)
categoria (no nulo),
ruc_proveedor (no nulo),
precio unitario no nulo,
ruc_proveedor llave primaria,
nombre_encargado no nulo,
empresa no nulo ,
Proveedor telefono nulo , CHECK (Telefono LIKE
'[076]%') CHECK ( Telefono LIKE ' [ 076 ]
%’)) Es decir que los numero de
celular de los meseros siempre
empezaran con 076.
dirección (nulo),
ciudad (no nula)
d. Modelo Entidad-Relación
e. Esquema Relacional
1. Proveedor (RUC, Nombre_Encargado, Empresa, Teléfono, Dirección, Ciudad)
2. Productos (ID_PRODUCTO, Categoría. Ruc_Proveedor, Precio)
3. Pedido (ID PEDIDO, Dni_cliente, DNI_empleado, fecha)
4. Cliente (DNI_cliente, Nombre. Apellido, Dirección, Teléfono)
5. Empleado (DNI_empleado, Celular, Nombres, Apellidos, Dirección)
f. Normalización del esquema Relacional
Proveedor
Comprobar si está en 1FN.
 Todos los atributos que tiene cada tabla son atómicos por lo tanto está en 1FN.
 Todos los atributos (que no son clave principal) deben depender de toda la clave.
 No hay atributos con clave compuesta, por lo tanto, está en 2FN.
 No deben existir dependencias transitivas entre atributos no clave
 No existen dependencias transitivas, por lo tanto, se encuentra en 3FN.
Productos
1) 1FN - ¿Atributos atómicos?
 Sí, es 1FN.
 ¿Cuál es la clave?
 ID_Producto
 2FN - ¿Todos los atributos (que no sean clave primaria) depende de toda la clave?
 Se comprueba que todos los atributos no clave dependen directamente de la clave

primaria.
 3FN - ¿Hay dependencias transitivas?
 No hay dependencia transitiva, así que satisface la 3FN

Pedido
 1FN - ¿Atributos atómicos?
 Sí, es 1FN.
 ¿Cuál es la clave?
 ID_Pedido
 2FN - ¿Todos los atributos (que no sean clave primaria) depende de toda la clave?

primaria.
 3FN - ¿Hay dependencias transitivas?
Empleado
 1FN - ¿Atributos atómicos?
 Sí, es 1FN.
 ¿Cuál es la clave?
 ID_Empleado
 2FN - ¿Todos los atributos (que no sean clave primaria) depende de toda la clave?

primaria.
 3FN - ¿Hay dependencias transitivas?
Cliente
 Todos los atributos que tiene cada tabla son atómicos por lo tanto está en 1FN.
 Todos los atributos (que no son clave principal) deben depender de toda la clave.
 No hay atributos con clave compuesta, por lo tanto, está en 2FN.
 No deben existir dependencias transitivas entre atributos no clave
 No existen dependencias transitivas, por lo tanto, se encuentra en 3FN.
g. Diseño Lógico.
+
h. Diseño Físico.
CREATE DATABASE pizzeria

use pizzeria
create table cliente (
DNI_cliente char (8) primary key,
nombre varchar (20) not null,
Apellidos varchar (20) not null ,
celular char (9) null,
direccion varchar (30) null,
CHECK (Celular LIKE '[9]%'))
create table contiene(

ID_pedido INT NOT NULL ,
id_productoP int not null,
id_productoS int not null)
create table empleado (

DNI_empleado char (8) primary key,
nombre varchar (20) not null,
Apellidos varchar (20) not null ,
celular char (9) null,
direccion varchar (30) null,
CHECK (Celular LIKE '[9]%'))
create table pedido (

ID_pedido INT IDENTITY (1,1) PRIMARY KEY,
Fecha_pedido DATE DEFAULT GETDATE() NOT NULL,
DNI_empleado char (8) not null,
DNI_cliente char (8) not null)
create table producto_principal(

id_productoP int IDENTITY (1,1) primary key,
categoria varchar (30) not null,
precio money not null,
Descripcion varchar (200))
create table producto_extra(

id_productoS int IDENTITY (1,1) primary key,
categoria varchar (30) not null,
ruc_proveedor char (11) null,
precio money not null,
Descripcion varchar (200))
create table proveedor (

ruc_proveedor char (11) primary key ,
nombre_encargado varchar (25) not null ,
empresa varchar (25) not null ,
telefono char (9) null ,
direccion char (25) null,
ciudad char (25) not null,
CHECK (Telefono LIKE '[076]%'))
alter table pedido

add foreign key (DNI_EMPLEADO) references EMPLEADO (DNI_EMPLEADO)
alter table PEDIDO
add foreign key (dni_cliente) references cliente (dni_cliente)
alter table contiene

add foreign key (id_pedido) references pedido (ID_pedido)
add foreign key (id_productoP ) references producto_Principal (id_productoP)
add foreign key (id_productoS ) references producto_extra (id_productoS)
alter table producto_extra

add foreign key (ruc_proveedor) references proveedor (ruc_proveedor)
INSERT INTO Cliente VALUES ('23453678','Juan','Perez Gomez','987654120','Jr.Mariano Melgar')

INSERT INTO Cliente VALUES ('23453679','Renato','Dominguez','987654126','Jr.Cruz de pierda 258')
INSERT INTO Cliente VALUES ('23453610','Jose','Lopez','987654129','Jr Mario urteaga 1587')
INSERT INTO Cliente VALUES ('23453611','Fernando','Carrión','987654124','Jr, el inca 166')
INSERT INTO Cliente VALUES ('23453145','Lorena','Bada','987654578','Jr.Amalia Puga 118 ')
INSERT INTO Cliente VALUES ('34562095','Valentina','Romero Padilla','976234109','Av.Magnolias')
INSERT INTO Cliente VALUES ('70676430', 'Majo','Leiva Pereyra','976342649','Av. Mansiche')
INSERT INTO Cliente VALUES ('70884123', 'Magaly Segunda','Salazar Diaz','986321597','Urb.
Primavera')
INSERT INTO Cliente VALUES ('17645978', 'Daniela','Mendez Peredo','946341547','Urb. San Isidro')
INSERT INTO Cliente VALUES ('70661176', 'Victor','Capristan Gomez','946341312','Urb. Santa Maria')
INSERT INTO Cliente VALUES ('77932155', 'Karla','Pereda Pereyra','946626882','Av. España')
INSERT INTO Cliente VALUES ('70568775', 'Diana','Olortegui Gil','979654213', 'Av. Vallejo')
INSERT INTO Cliente VALUES ('34526745', 'Pedro','Morales Castañeda','976345749', 'Av. La paz')
INSERT INTO Cliente VALUES ('67548934', 'Jose','Perez Olivares','976245367','Jr. Junin')
INSERT INTO Cliente VALUES ('65839255', 'Juan', 'Culqui Terrons','934578234','Jr Ayacucho')
INSERT INTO Cliente VALUES ('26967241', 'Clara', 'Córdova Linares','976309612','Jr Amancaes')
INSERT INTO Cliente VALUES ('75839472', 'Liz', 'Perez Prado','934230182','Av San Lorenzo')
INSERT INTO Cliente VALUES ('74256325', 'Maribel', 'Rodriguez Polar','976723124','Av San Torini')
INSERT INTO Cliente VALUES ('46234947', 'Pedro', 'Quiroz Gonsalez','922455537','Jr. Mariano
Melgar')
INSERT INTO Cliente VALUES ('57098123', 'María','Nuñez Coello','943729542','Av Hoyos Rubio')
INSERT INTO Cliente VALUES ('74363932', 'Rosa', 'Alvarado Franco','964799452','Av El Maestro')
INSERT INTO Cliente VALUES ('78325762', 'Angel', 'Marin Rosas','924367190','Av San Martín')
INSERT INTO Cliente VALUES ('56234817', 'Peter ', 'Perez Roncal','976453920','Jr Junin')
INSERT INTO Cliente VALUES ('22539734', 'Pamela', 'Nuñez Mendoza','986453628','Av Mario Urteaga')
INSERT INTO Cliente VALUES ('27468564', 'Sara', 'Taita Rojas','954302676','Jr Los Pinos')
INSERT INTO Cliente VALUES ('26935638', 'Georgina', 'Huaman Torres','934562927','Jr Amazonas')
INSERT INTO Cliente VALUES ('26486464', 'Elvis', 'Barboza Gonzales','984543720','Jr Miguel Grau')
INSERT INTO Cliente VALUES ('26945824', 'Jeyson', 'Ventura Taita','976593827','Jr Miguel Grau')
INSERT INTO Cliente VALUES ('42379823', 'Kevin', 'Cruz Córdova','976453212','Jr Chanchamayo')
INSERT INTO Cliente VALUES ('25374959', 'Gerard', 'Mercado Rodriguez','920864738','Av El Maestro')
INSERT INTO Cliente VALUES ('23453671', 'Pedro', 'Sanchez Guevara','976234673','Av Tahuantinsuyo')
INSERT INTO Cliente VALUES ('34527859', 'Jorge', 'Perez Gonzales','974536210','Jr. Pedro Ruiz')
INSERT INTO Cliente VALUES ('23145628', 'Valeria', 'Romero Saenz','974536210','Jr. Ayacucho')
INSERT INTO Cliente VALUES ('45637829', 'Juan', 'Mestanza Torres','953678290','Jr. El Comercio')
INSERT INTO Cliente VALUES ('23453786', 'Linda', 'Campos Lara','965834281','Jr. Los Pinos')
INSERT INTO Cliente VALUES ('45362990', 'Jorge', 'Ramirez Peredo','943785901','Jr.Puente')
INSERT INTO cliente VALUES ('55639011', 'Ramona', 'Catrejon Puente','982541122','Jr. Cruz de
Piedra')
INSERT INTO cliente values ('76889022', 'Octavio', 'Dávila Huerta','976322144','Jr. Del Comercio')
INSERT INTO Cliente VALUES ('29954677', 'Fernanda', 'Paredes Saenz','988976345','Jr. Puno')
INSERT INTO Cliente VALUES ('66409836', 'Luz', 'Guarniz Mendoza','995644101','Jr. Huánuco')
INSERT INTO Cliente VALUES ('82774509', 'Nancy', 'Infante Quiste','967548093','Jr. Los Pinos')
INSERT INTO Cliente VALUES ('56774432', 'Pamela', 'Nuñez Coello','976342199','Av. Perú')
INSERT INTO Cliente VALUES ('23761003', 'lizbeth', 'Nordy Capristán','987213445','Av. Monte')
INSERT INTO Cliente VALUES ('34522390', 'Laura', 'Huaman Campos','976239098','Av. Peru')
INSERT INTO Cliente VALUES ('23453678','Juan','Perez Gomez','987654120','Jr.Mariano Melgar')
INSERT INTO Cliente VALUES ('23453679','Renato','Dominguez','987654126','Jr.Cruz de pierda 258')
INSERT INTO Cliente VALUES ('23687454','Fernando','Carrion','984757888','Jr.Belen')
INSERT INTO Cliente VALUES ('26684751','Carlos','Sanchez','987548918','Jr.Apurimac 452')
INSERT INTO Cliente VALUES ('25458745','Roberto','Alcantara','960717452','Jr.Dos de Mayo 248')
INSERT INTO Cliente VALUES ('29475871','Paul','Chavez','972415214','Jr.Del Comercio 625')
INSERT INTO Cliente VALUES ('28471265','Omar','Briceño','976372473','Jr.Guillermo Urrelo 620')
INSERT INTO Cliente VALUES ('21241541','Erika','Caceres','915478523','Jr.Los Gladiolos 320')
INSERT INTO Cliente VALUES ('27411523','Eliana','Carrion','954354440','Jr.Jose Sabogal 982')
INSERT INTO Cliente VALUES ('27214541','Daniel','Camacho','976372472','Jr.Revilla Perez')
INSERT INTO Cliente VALUES ('21145215','Manuel','Cortez','921451423','Jr.Amazonas 222')
INSERT INTO Cliente VALUES ('24875129','William','Alva','949384751','Jr.Dos de Mayo 632')
INSERT INTO Cliente VALUES ('23654785','Jose','Cotrina','919068495','Jr.Belen')
INSERT INTO Cliente VALUES ('28471026','Armando','Asenjo','920145144','Jr.Diego Ferre')
INSERT INTO Cliente VALUES ('29145660','Carlos','Vasquez','925167841','Jr.Apurimac 822')
SELECT *
FROM CLIENTE
INSERT INTO Empleado VALUES ('72737313', 'Grace','Yalán Sanchez','988644122','Urb. Santa Maria')
INSERT INTO Empleado VALUES ('23451098', 'Isabel','Arias Putin','966789134','Av. Perú')
INSERT INTO Empleado VALUES ('34261872', 'Andrés','Pacsi Montoya','977655443','Jr. Chanchamayo')
INSERT INTO Empleado VALUES ('23109864', 'Fernando','Cirulo Mondragón','944567107','Jr.La Paz')
INSERT INTO Proveedor VALUES('19853729863','Mario Mendoza','PIQUEOS','076213809','Jr.el inca
','CAJAMARCA')
INSERT INTO Proveedor VALUES('97458632106','Leonardo
Chavez','Cocacola','076213809','Jr.Angamos','CAJAMARCA')
INSERT INTO Proveedor VALUES('14756348965','Andre Escalante','Bacus','076213809','Jr.san
martin','CAJAMARCA')
INSERT INTO producto_extra VALUES ('Free papas','19853729863', '1', 'Free papas de 50g')
INSERT INTO producto_extra VALUES ('GASEOSA', '97458632106', '6', 'Gaseosa Inca cola de litro')
INSERT INTO producto_extra VALUES ('GASEOSA', '97458632106', '3', 'Gaseosa Coca Cola personal')
INSERT INTO producto_extra VALUES ('GASEOSA', '97458632106', '3', 'Gaseosa Inca cola personal')
INSERT INTO producto_extra VALUES ('GASEOSA', '97458632106', '6', 'Coca cola de litro')
INSERT INTO producto_extra VALUES ('GASEOSA', '97458632106', '10', 'Gaseosa Inca cola de 3 litros')
INSERT INTO producto_extra VALUES ('GASEOSA', '97458632106', '10', 'Gaseosa Coca cola de 3 litros')
INSERT INTO producto_extra VALUES ('Cerveza', '14756348965', '6', 'Cerveza Cusqueña de 750
mililitros')
INSERT INTO producto_extra VALUES ('Cerveza', '14756348965', '5', 'Cerveza Cristal de 750
mililitros')
INSERT INTO producto_principal VALUES ('Pizza', '24', 'pizza Familiar')

INSERT INTO producto_principal VALUES ('Pizza', '32', 'extra grande ')
INSERT INTO producto_principal VALUES ('Pizza', '16', 'pizza personal')
INSERT INTO pedido (DNI_cliente, DNI_empleado) VALUES ('23453678', '72737313')

INSERT INTO pedido (DNI_cliente, DNI_empleado) VALUES ('23453679','23451098')
INSERT INTO PEDIDO (DNI_CLIENTE, DNI_EMPLEADO) VALUES ('29475871','23109864')
SELECT *
FROM PEDIDO
INSERT INTO CONTIENE VALUES ('1','5','6')

/* 1 mostrar los nombres de los clientes y los detalles de sus pedidos*/
select c.nombre , c.Apellidos , pp.Descripcion as ' producto principal', pp.precio , pe.Descripcion

as 'producto secundario', pe.precio
from cliente as c inner join pedido as p on p.DNI_cliente = c.DNI_cliente inner join
contiene as co on co.ID_pedido=p.ID_pedido inner join producto_principal as pp on
pp.id_productoP=co.id_productoP
inner join producto_extra as pe on co.id_productoS=pe.id_productoS
/* 2 mostrar detalles de las ventas de por cada empleado */
select e.nombre as ' Nombre Empleado' , c.nombre as 'Nombre Cliente', PP.Descripcion as 'Producto
Principal',
pp.precio , pe.Descripcion as 'Producto Secundario', pe.precio , p.Fecha_pedido
from empleado as e inner join pedido as p on e.DNI_empleado=p.DNI_empleado inner join cliente as c
on p.DNI_cliente = c.DNI_cliente inner join contiene
co on co.ID_pedido=p.ID_pedido inner join producto_principal as pp on
/* 3 mostrar los 3 productos mas caros*/
select top 3 precio

from producto_principal
order by precio desc
/* 4 mostrar los datos de los proveedores y sus productos */
select * from proveedor as p inner join producto_extra as pe on pe.ruc_proveedor=p.ruc_proveedor
/* 5 mostrar la cantidad vendida por cada empleado */
select e.nombre, e.Apellidos , sum(pp.precio + pe.precio) as 'Total Vendido'

from empleado as e inner join pedido as p on e.DNI_empleado=p.DNI_empleado inner join cliente as c
on p.DNI_cliente = c.DNI_cliente inner join contiene
co on co.ID_pedido=p.ID_pedido inner join producto_principal as pp on
group by e.nombre, e.Apellidos
/* 6 productos vendidos a cada cliente*/
SELECT C.nombre AS CLIENTE, pp.Descripcion as producto_principal, pe.Descripcion as

producto_secundario
FROM CLIENTE AS C INNER JOIN pedido AS P ON C.DNI_cliente = P.DNI_cliente INNER JOIN contiene AS CO
ON P.ID_pedido = CO.ID_pedido
INNER JOIN producto_extra AS PE ON PE.id_productoS=CO.id_productoS INNER JOIN producto_principal AS
PP on pp.id_productoP= co.id_productoP
/* 1 crear una vista donde podamos ver las compras de los clientes */
CREATE VIEW vista_detalles_pedido_cliente

AS
select c.nombre , c.Apellidos , pp.Descripcion as ' producto principal', pp.precio as 'Precio
Producto Principal' , pe.Descripcion as 'producto secundario', pe.precio as 'Precio Producto Extra'
from cliente as c inner join pedido as p on p.DNI_cliente = c.DNI_cliente inner join
contiene as co on co.ID_pedido=p.ID_pedido inner join producto_principal as pp on
select*
from vista_detalles_pedido_cliente
/* 2 crear una vista donde veamos los datos de los empleados*/

create view Datos_empleado
as
select *
from empleado
/* 3 crear una vista que muestre los productos y sus proveedores*/
create view Productos_Proveedores

as
select pe.Descripcion as ' Nombre del Producto', p.empresa ' Empresa Proveedora'
from producto_extra as pe inner join proveedor as p on pe.ruc_proveedor=p.ruc_proveedor
/*Crear procedimiento almacenado donde se vean los detalles del pedido ingresando el id del pedido
*/
CREATE PROCEDURE SP_detalle_pedido6

@idpedido int
AS
SELECT p.Fecha_pedido, cl.nombre as nombre_cliente , e.nombre as nombre_empleado , pp.Descripcion
as producto_principal , pp.precio , pe.Descripcion as producto_secundario, pe.precio,
p.ID_pedido
FROM pedido as p inner join contiene as c on c.ID_pedido=p.ID_pedido inner join producto_extra
as pe on pe.id_productoS=c.id_productoS inner join producto_principal as pp on
pp.id_productoP=c.id_productoP
inner join cliente as cl on cl.DNI_cliente=p.DNI_cliente inner join empleado as e on
e.DNI_empleado=p.DNI_empleado
where @idpedido=p.ID_pedido
GO
EXEC SP_detalle_pedido6
@idpedido=6
/*Crear procedimiento almacenado donde veamos los clientes atendidos por el empleado ingresando su
DNI*/
create procedure sp_empleado_cliente1
@DNI_empleado char (8)
as
select p.Fecha_pedido, cl.nombre as nombre_cliente , e.nombre as nombre_empleado , pp.Descripcion
as producto_principal , pp.precio , pe.Descripcion as producto_secundario, pe.precio,
p.ID_pedido
FROM pedido as p inner join contiene as c on c.ID_pedido=p.ID_pedido inner join producto_extra
as pe on pe.id_productoS=c.id_productoS inner join producto_principal as pp on
pp.id_productoP=c.id_productoP
inner join cliente as cl on cl.DNI_cliente=p.DNI_cliente inner join empleado as e on
e.DNI_empleado=p.DNI_empleado
where @DNI_empleado=e.DNI_empleado
exec sp_empleado_cliente1
@DNI_empleado = 72737313
/*Crear procedimiento almacenado donde veamos los productos de los proveedores ingresando su RUC */
create procedure SP_Proveedores_productos

@ruc_proveedor char (11)
as
select * from proveedor as p inner join producto_extra as pe on p.ruc_proveedor=pe.ruc_proveedor
where @ruc_proveedor = p.ruc_proveedor
exec SP_Proveedores_productos
@ruc_proveedor = 14756348965
/* Crear un procedimiento almacenado donde veamos todos los pedidos del cliente y sus detalles,
colocando su DNI */
create procedure sp_CLientes_pedidos1
@DNI_cliente char(8)
as
select * from cliente as c inner join pedido as p on p.DNI_cliente=c.Dni_cliente inner join
contiene as co on co.ID_pedido=p.ID_pedido
inner join producto_principal as pp on pp.id_productoP=co.id_productoP inner join producto_extra
as pe on pe.id_productoS = co.id_productoS
where @DNI_cliente=c.DNI_cliente
exec sp_CLientes_pedidos1
@dni_cliente=23453679
EXCEL
Mostrar productos principales y secundarios y sus precios

Mostrar los empleados y los productos que atendieron
Mostrar detalles de las ventas de cada empleado

Generador de informes
Mostrar la cantidad vendida por cada empleado

Base de Datos FINAL

Cargado por

Copyright:

Formatos disponibles

Base de Datos FINAL

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Base de Datos FINAL

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA

CARRERA “INGENIERÍA EMPRESARIAL”

“DISEÑO E IMPLEMENTACIÓN DE BASE DE DATOS PARA LA

EMPRESA BAMBINO PIZZA”

Gestión de Base de Datos

César Augusto Díaz Camacho

Héctor Martin Aguilar López

Rodríguez Quiliche, Roberto Carlos

Camacho Alva Violeta Lidiel

Ing. Paul Omar Cueva Araujo

El objetivo de la presente investigación es ordenar y mejorar el sistema interno y estructural

Bambino Pizza es una pizzería orgullosa de ser cajamarquina, con el mejor

- Ordenar y mejorar el sistema interno y estructural de la empresa ·”Bambino pizza” a

- En caso de que haya alguna pérdida de información de la empresa tener el

III. Marco Teórico

Un sistema gestor de base de datos es un conjunto de programas que permiten el almacenamiento,

Un Sistema de Gestión de Bases de Datos consiste en una colección de datos interrelacionados y un

El término campo es incorrectamente intercambiado con el de columna, el término correcto a

En informática, o concretamente en el contexto de una base de datos relacional, un registro (también

Es Simplemente la forma en que se relacionan las Entidades, o expresa cuantas entidades se

La normalización es un concepto que hace referencia a las relaciones. Básicamente, el principio de

xii. Diagrama Entidad-Relación

xv. Esquema Relaciona

En el modelo relacional se basa en el concepto matemático de relación. En este modelo, la

xvii. Tipos de datos (SQL)

xviii. Diseño Físico de Base de Datos

El lenguaje estructurado de consultas (SQL, Structured Query Language) apoya la creación y

SQL es un lenguaje de dominio específico utilizado en programación, diseñado para administrar, y

DML ayuda y es importante porque inserta, suprime y modifica filas de tablas.

xxiv. SQL Server

xxv. Transact SQL

xxvi. Consultas (Base de Datos)

xxvii. Subconsultas (Base de Datos)

xxviii. Algebra relacional

xxix. Vistas (Base de datos)

Una vista materializada es un objeto de la base de datos almacenado en el dispositivo de

xxxi. Procedimientos almacenados (Stored Procedures)

Un procedimiento almacenado de SQL Server es un grupo de una o varias instrucciones Transact-

Un procedimiento almacenado es un programa almacenado físicamente en una base de datos. Su

a. Datos Completos de la Empresa

Ser reconocidos como la organización operadora de restaurantes más confiable y

Bambino pizza se especializa por la preparación de:

 Datos Importantes de la empresa:

Razón Social: BAMBINO PIZZA E.I.R.L

Dirección: JR. SILVA SANTISTEBAN NRO. 141

TABLAS ATRIBUTOS (RESTRICCIONES)

id_producto (INT IDENTITY, es decir

1. Proveedor (RUC, Nombre_Encargado, Empresa, Teléfono, Dirección, Ciudad)

2. Productos (ID_PRODUCTO, Categoría. Ruc_Proveedor, Precio)

3. Pedido (ID PEDIDO, Dni_cliente, DNI_empleado, fecha)

4. Cliente (DNI_cliente, Nombre. Apellido, Dirección, Teléfono)

5. Empleado (DNI_empleado, Celular, Nombres, Apellidos, Dirección)

f. Normalización del esquema Relacional

 Todos los atributos (que no son clave principal) deben depender de toda la clave.

 No hay atributos con clave compuesta, por lo tanto, está en 2FN.

 No existen dependencias transitivas, por lo tanto, se encuentra en 3FN.

1) 1FN - ¿Atributos atómicos?

 Se comprueba que todos los atributos no clave dependen directamente de la clave

 3FN - ¿Hay dependencias transitivas?