Grupo : …..

Alumno: Angelo Augusto Gallici Aquino

DISEÑO DE BASES DE DATOS

Actividad Integradora N° 2

Una empresa de fabricación y armado de maquinaria especial desea construir una base de datos relacional para mantener
información relacionada de la estructura de sus productos. Para ello se realiza un relevamiento de la misma obteniéndose como
resultado lo siguiente:

 Cada PARTE posee un código de identificación (de un máximo de 10 caracteres alfanuméricos), una denominación
(nombre descriptivo que no se puede repetir), un código de Tipo de parte (pieza, materia prima, conjunto, o pieza de
tercero), y un campo de hasta 255 caracteres para observaciones. En otro campo se indica el legajo del diseñador
responsable (solo se usaría para pieza y conjuntos).

 Cada PARTE (por lo general de tipo “CONJUNTO”) puede estar formada por varias PARTES (COMPONENTES), cada uno de
los cuales con una determinada cantidad, y en una determinada UNIDAD de medida (kilo, metro, unidad, litro, etc) .

 Los Tipos de Partes están codificadas en una tabla, al igual que las Unidades de medidas.

 Todo el personal de planta se encuentra registrado en una entidad LEGAJOS (jefes, empleados, diseñadores, etc),
identificados por el número de legajo, tipo y número de documento, apellido, nombre, fecha de ingreso, cargo y
domicilio)

1. Realizar el diagrama entidad-relación de una base de datos normalizada para el caso planteado, utilizando un modelo de
diagrama de acuerdo a la guía, ó utilizando alguna herramienta CASE (como PowerDesigner, Erwin o MySQL
Workbench).
(La consigna puede resolverse con 5 entidades.)

2. Realizar un cuadro resumen, identificando las claves primarias (PK), foráneas (FK) y alternativas (AK), utilizando el
siguiente formato:

Tabla Claves Clave Principal Claves Claves ajenas

candidatas Alternativas (indicar tabla relacionada)
3. Para cada caso, elegir una relación entre tablas y justificar la aplicación de la reglas para ACTUALIZACIÓN (ó
ELIMINACION) de claves primarias:

Regla de ACTUALIZACIÓN – RESTRINGIDA

Relación: (tabla Partes.id_tipo_parte) -> (tabla Tipo de parte.id_tipo_parte)
Justificación: La restricción en caso de actualización consiste en no permitir modificar ningún atributo de la clave primaria de
una tupla si tiene una clave primaria referenciada por alguna clave foránea. Con estas tablas significa que no podemos
actualizar el id_tipo_parte ya que esta referenciado a la tabla de Partes y por lo tanto al cambiar un tipo de partes no
coincidiría con el tipo en la tabla Partes, deberían actualizarse ambos.

Regla de ACTUALIZACIÓN – CASCADA (se propaga)

Relación: (tabla Partes.id_legajo_diseñador) -> (tabla Legajos.id_legajo)
Justificación: La actualización en cascada en caso de modificación consiste en permitir la modificación de atributos de la
clave primaria de una tupla t que tiene una clave primaria referenciada, y modificar del mismo modo todas las tuplas que
referencian t. En este caso como la clave primaria es de Legajos-id_legajo y esta referenciada por id_legajo_diseñador en
Partes; si se modifica el legajo del diseñador en Legajos también se modificara en Partes para que concuerde que quien esta
como empleado es quien es responsable de pieza o conjunto.

Regla de ELIMINACION – RESTRINGIDA

Relación: (tabla Componentes.id_parte) -> (tabla Partes.id_parte)
Justificación: La restricción en caso de borrado, consiste en no permitir borrar una tupla si tiene una clave primaria
referenciada por alguna clave foránea. Aquí seria que si deseamos borrar la clave primaria id_parte de Partes no podríamos
porque esta referenciada por el mismo campo en Componentes ya que varios componentes (partes) forman una parte del
tipo conjunto.

Regla de ELIMINACION – CASCADA (se propaga)

Relación: (tabla Partes.id_tipo_parte) -> (tabla Tipo de parte.id_tipo_parte)
Justificación: La eliminación en cascada consiste en permitir el borrado de una tupla t que tiene una clave primaria
referenciada, y borrar también todas las tuplas que referencian t. Es decir que si borramos en la clave primaria de Tipos de
parte también se borrara ese campo en Partes ya que seria como un sub índice donde cada parte se identifica por su
id_parte y su id_tipo_parte, por lo que si se elimina en la tabla principal también lo hará en la referenciada.

4. Seleccionar un DBMS (Microsoft Access, MySQL, DB2, SQL Server u otro), indicar la elección, y generar para el mismo el
conjunto de sentencias en SQL para la creación de al menos 4 tablas, considerando las distintas claves definidas y las
relaciones entre las mismas.

5. Transcribir las consultas SQL para obtener los siguientes listados:

 1. Lista de Partes que empiecen con la letra ‘A’ , ordenados por Tipo, y luego alfabéticamente por Código(de menor a
mayor)
[Código] [Denominacion] [Tipo de Parte]

2. Listado de Conjuntos y Cantidad de Partes que los componen, ordenados por Tipo
[Nombre Conjunto] [Cant. de Partes]

3. La Parte más utilizada como COMPONENTE (puede ser un listado ordenado adecuadamente)
[Codigo Parte] [Cant. De veces que se utiliza] Aquí hacemos un supuesto de trabajo respecto al tipo de parte que
predomina por mayoría respecto a los demas

4. Las Partes que no pertenecen a ningún conjunto (o sea no es COMPONENTE de ninguno)

[Codigo Parte]

5. Realice y justifique un TRIGGER que permita llevar un historial de modificaciones de PARTES en otra
entidad. Los campos de la nueva entidad queda a su criterio.

Nota
Si considera que en algún punto la información es insuficiente o incompleta para definir algún consigna o elemento,
deberá definir un ‘supuesto’ de trabajo y resolver el problema de acuerdo a esta pauta, de manera tal que el trabajo
no se vea estancado por alguna cuestión de esta índole; en la evaluación del presente considerará positivamente
todas estas aclaraciones.

1)
2)

3)
REALIZADA EN LA MISMA CONSIGNA

4) SQL SERVER
create database AO2

use AO2

create table Tipo_de_parte(

id_tipo_parte varchar (30) not null primary key,
nombre varchar (30))

create table Componentes(

id_parte varchar(30) primary key,
unidad_medida varchar (10),
cantidad varchar (30)
foreign key (id_parte) references Partes(id_parte))

create table Partes(

id_parte varchar(30)not null,
denominacion varchar(30) not null,
id_tipo_parte varchar(30),
observaciones varchar(255),
id_legajo_diseñador varchar (30)
primary key (id_parte,denominacion)
foreign key (id_tipo_parte) references Tipo_de_parte(id_tipo_parte)
)

create table Legajos(

id_legajo varchar (30) not null primary key,
tipo_documento varchar(30),
num_documento varchar(30),
nombre_apellido varchar (100),
 fecha_ingreso datetime,
cargo varchar (100),
domicilio varchar (100)
foreign key (id_legajo) references Partes(id_legajo_diseñador))

5.1)

5.2)

CON
SULT
AS

Unión de
consultas

5.3)

5.4)
5)
create database AO2

use AO2

create table Parte(

id_parte varchar (30) not null primary key,
denominacion varchar (30),
id_tipo_parte varchar (30),
observaciones varchar (255),
id_legajo_diseñador varchar (30))

create table historial_partes(

id_parte_historial varchar (30) not null primary key,
denominacion_historial varchar (30),
id_tipo_parte_historial varchar (30),
observaciones_historial varchar (255),
id_legajo_diseñador_historial varchar (30))

insert into Parte values ('b2b2','materia prima','1','recurso natural','150')

create trigger tr_parte

on Partes
after update
as
begin
insert historial_partes select * from Parte
end

update Parte set id_parte='a1a1', denominacion='pieza',id_tipo_parte='3',observaciones='pieza de

maquinaria',id_legajo_diseñador='100'

select * from Parte

select * from historial_partes