Desarrollo entidad relacion bases de datos basico-colaborativo2

FASE 2 TRABAJO COLABORATIVO 2

DIEGO FERNANDO GONZALEZ COD: 94325163 94325163 RICARDO SUAREZ GALVIS COD: 1113676 1113676160 160 FLOWER ANDRES PENAGOS PORTILLA: 1085317313 1085317313

Curso: BASES DE DATOS BASICO Grupo: 36

Tutor: IVAN VELOZA

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA PROGRAMA DE INGENIERÍA DE SISTEMAS 2018-II

TABLA DE CONTENIDO

1. OBJETIVOS. 2. TABLA CON ENLACES GOOGLE GOOGLE DRIVE. DRIVE. 3. INTRODUCCIÓN. 4. DESARROLLO ACTIVIDAD 5. CONCLUSIONES 6. BIBLIOGRAFIA

1. OBJETIVOS

-Reconocer el esquema lógico como fuente de información para el diseño físico. -Reconocer que es el diseño lógico y cuál es su inferencia en el proceso de construcción de esquemas de información. -Reconocer que es el diseño físico y cuál es su proceso en la implementación de la base de datos. -Reconocer cual es el propósito del diseño físico.

2. TABLA CON LOS ENLACES A GOOGLE DRIVE DE CADA INTEGRANTE.

Estudiante Enlace Diego Fernando González FLOWER ANDRES PENAGOS RICARDO SUAREZ

(Bitácora indivi dual)

https://drive.google.com/open?id=1Sv4chJbdSf8AtLJkU4aOsWC-p4RRBBQ0

https://drive.google.com/file/d/1oWLP_OOuEIgF3ualBcho8U2ba8dQuGTS/view?usp=shari ng https://drive.google.com/folderview?id=19NuKc_QkyZHDuvGXgpNMA1z5e9WNPpzL

3. INTRODUCCION

El diseño de una Base de Datos es un proceso complejo que abarca decisiones a muy distintos niveles. La complejidad se controla mejor si se descompone el problema en subproblemas y se resuelve cada uno de estos. Por medio de esta actividad aprenderemos a validar el tipo de información que se quiere almacenar en ella, teniendo en cuenta la que está disponible y la que se va a necesitar. La información a incorporar a una BD se obtiene durante las distintas etapas de diseño de la misma.

4. DESARROLLO ACTIVIDAD

a. Resultado de la transformación del Modelo Entidad Relación a la primera versión del Modelo Relacional (Modelo Lógico) siguiendo las siguientes indicaciones: Descripción del proceso: Se trata de una base de datos con la información de los empleados, cargos y departamentos de una empresa donde se concentra la información personal de cada uno de ellos; recibiremos y almacenaremos identificación, nombre, segundo nombre, primer apellido, segundo apellido, fecha nacimiento, fecha ingreso, salario, estado civil, sexo, correo, nombre cargo, identificación cargo, nombre departamento identificación del departamento. 1. Transforme entidades en tablas Tenemos 3 conjuntos de entidades: Empleados, Departamentos y Cargos.

2. Transforme atributos en columnas Tenemos para la entidad Empleados la almacenaremos identificación, nombre, segundo nombre, primer apellido, segundo apellido, fecha nacimiento, fecha ingreso, salario, estado civil, sexo, correo. Para el caso de Departamentos serian nombre departamento identificación del departamento y con la entidad Cargo tenemos nombre cargo, identificación cargo.

Modelo entidad- relación

Modelo relacional

entidad

tabla

atributo

columna

Único Identificador

Clave primaria

Relación 1:m

Esta llave es única y la cual a ir insertada en otras tablas

Relación M:M

Se hace la realización de la tabla con su llave y esta estará unida a otra tabla ya creada.

Relación 1:1

Esta llave va hacer ingresada a otra tabla

Generalización:

La llave pasara a otras tablas.

3. Agregar a cada tabla un identificador único (UID) o primary key. Clave primaria (primary key): Hace que los atributos marcados como clave primaria no puedan repetir valores. Además obliga a que esos atributos no puedan estar vacíos. Si la clave primaria la forman varios atributos, ninguno de ellos podrá estar vacío. En este caso tenemos id empleados en la Tabla Empleados, id cargo en la Tabla Cargo e id departamentos en la Tabla departamentos.

4. Transforme las relaciones 1:1 o 1: m en llaves foráneas, implementando el concepto de la integridad referencial. Integridad referencial (foreign key): significa que la clave externa de una tabla de referencia siempre debe aludir a una fila válida de la tabla a la que se haga referencia. La integridad referencial garantiza que la relación entre dos tablas permanezca sincronizada durante las operaciones de actualización y eliminación.

Relacion1: Esta relación modela un hecho importante que sucede en el proceso que estamos analizando y es que un empleado puede dirigir a otros empleados y que los empleados de la organización pueden ser dirigidos por otro empleado. - Las relaciones reflexivas o recursivas se tratan de la misma forma que las otras, sólo que un mismo atributo puede figurar dos veces en una tabla como resultado de la transformación. 1 a-Muchos (1: N) -1ra llave foránea Relacion2: Esta relación modela que un empleado trabaja en un departamento de la organización y que un departamento de la compañía puede ser ocupado por muchos empleados. 1 a –Muchos (1: N) -2da llave foránea

Relacion3: modela que un Empleado puede dirigir muchos Departamentos de la organización y que los Departamentos pueden ser dirigidos por un empleado. 1 a –Muchos (1: N) – 3ra llave foránea

Relacion4: modela que un Empleado puede Ocupar un Cargo de la organización y que un Cargo puede ser realizado por muchos Empleados. 1 a –Muchos (1: N) -4ta llave foránea

Modelo Entidad - Relación

Modelo Relacio nal

Entidad

Empleado

At ri bu to

Empleado_ID, Nombres, Apellidos, F_Nacimiento, F_Ingreso, Salario, Sexo.

Identificador único

Empleado_ID

Relación 1:M

Cargos;

Relación M:M

N/A

Relación 1:1

Departamentos

Generalización/Especialización

La llave primaria de la tabla dominante pasara como llave foránea en las tablas dependientes


Modelo Relacional

Entidad

Departamentos

At ri bu to

Departamento_ID, Empleado_ID, Cargo_ID, Nombre del departamento.


Departamento_ID

Relación 1:M

Empleados; cargos.

Relación M:M

N/A

Relación 1:1

N/A




Modelo Relacio nal

Entidad

Cargos

At ri bu to

Cargo_ID, Empleado_ID, Departamento_ID, Nombre del cargo.


Cargo_ID

Relación 1:M

Empleados

Relación M:M

N/A

Relación 1:1

Departamentos



5. Aplicar técnicas de normalización. La normalización es una técnica que busca dar eficiencia y fiabilidad a una BD relacional. Su objetivo es, por un lado, llevar la información a una estructura donde prime el aprovechamiento del espacio; y por otro lado, que el manejo de información pueda llevarse a cabo de forma rápida. Cuando realizamos el diseño en el modelo relacional existen diferentes alternativas, pudiéndose obtener diferentes esquemas relacionales. No todos ellos serán equivalentes y unos representarán mejor la información que otros. Las tablas obtenidas pueden presentar problemas tales como: -Redundancia. Se llama así a los datos que se repiten continua e innecesariamente por las tablas de las bases de datos. Cuando es excesiva es evidente que el diseño hay que revisarlo, es el primer síntoma de problemas y se detecta fácilmente. -Ambigüedades. Datos que no clarifican suficientemente el registro al que representan. Los datos de cada registro podrían referirse a más de un registro o incluso puede ser imposible saber a qué ejemplar exactamente se están refiriendo. -Pérdida de restricciones de integridad. Normalmente debido a dependencias funcionales. -Anomalías en operaciones de modificación de datos. El hecho de que al insertar un solo elemento haya que repetir tuplas en una tabla para variar unos pocos datos. O que eliminar un elemento suponga eliminar varias tuplas necesariamente (por ejemplo que eliminar un empleado suponga borrar seis o siete filas de la tabla de empleados, sería un error muy grave y por lo tanto un mal diseño).

FORMAS NORMALES -La normalización nos permite eliminar estos problemas, forzando a la división de una tabla en dos o más. -Las formas normales se corresponden a una teoría de normalización iniciada por Edgar F. Codd y continuada por otros autores (entre los que destacan Boyce y Fagin). Codd definió en 1970 la primera forma normal. Desde ese momento aparecieron la segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma normal. En este documento sólo consideraremos las tres primeras formas normales. -Una tabla puede encontrarse en primera forma normal y no en segunda forma normal, pero no al contrario. Es decir los números altos de formas normales son más restrictivos.

Primera forma normal (1FN) Es una forma normal inherente al esquema relacional, por lo que su cumplimiento es obligatorio; es decir toda tabla realmente relacional la cumple. Se dice que una tabla se encuentra en primera forma normal si EMPLEADO NOMBRE

Departamento

Elías

Informática

David

Coordinación Mantenimiento

Para resolver este problema simplemente se descomponen aquellas tuplas en los que los atributos tienen más de un valor en tantas tuplas como valores haya, cada una con un valor. La siguiente relación sí cumple la primera forma normal:

EMPLEADO NOMBRE

Departamento

Elías

Informática

David

Coordinación

David

Mantenimiento

Segunda forma normal (2FN) Ocurre si una tabla está en primera forma normal (1FN) y además cada atributo que no sea clave, depende de forma funcional completa respecto de cualquiera de las claves. Toda la clave principal debe hacer dependientes al resto de atributos, si hay atributos que dependen sólo de parte de la clave, entonces esa parte de la clave y esos atributos formarán otra tabla.

Empleado. DNI

CodCargo

Nombre

salario

31777999

34

Elías

10

31777999

25

Elías

9

31555222

34

Luisa

8

31456712

25

David

6

31456712

34

David

7

En este ejemplo suponiendo que el DNI y el código de cargo forman la clave principal para esta tabla, sólo el salario tiene dependencia funcional completa. El nombre depende de forma completa del DNI. La tabla no satisface la segunda forma normal (no es 2FN). Para arreglarlo separamos la tabla en dos.

Empleado DNI

Nombre

31777999

Elías

31555222

Luisa

31456712

David

Cargo DNI

CodCargo

salario

31777999

34

10

31777999

25

9

31555222

34

8

31456712

25

6

31456712

34

7

Tercera forma normal (3FN): Ocurre cuando una tabla está en segunda forma normal (2FN) y además ningún atributo que no sea clave depende funcionalmente de forma transitiva de la clave primaria. Ejemplo:

Empleado DNI

Nombr e

CodDepartamento

Departamento

31777999

Elías

11

Cocina

31777111

Pepe

41

Servicio al cliente

31555222

Rosa

29

Mantenimiento

31717171

Juana

11

Coordinador

12002003

Manuela

08

Mensajería

-Observamos que Departamento depende funcionalmente del código de

Departamento, lo que hace que no esté en 3FN. El arreglo sería:

Empleado DNI

Nombr e

CodDepartamento

31777999

Elías

11

31777111

Pepe

41

31555222

Rosa

29

31717171

Juana

11

Departamento CodDepartamento

CodDepartamento

11

Cocina

29

Mantenimiento

08

Mensajería

41

Servicio al cliente

Diseño lógico

b.Después de aplicar las anteriores acciones sobre el Modelo Entidad Relación de la etapa de análisis, debe obtener la Versión preliminar del Modelo Relacional (Modelo Físico) con su respectivo diccionario de datos así: 1. Descripción de Tablas 2. Descripción de Columnas y las restricciones (Constraints) 3. Descripción de Llaves Foráneas 4. Diseño funcional del Modelo Entidad Relación en la herramienta Data Modeler.

Modelo físico

DICCIONARIO

Design Name

DiseÃ±oBDB

Version Date Version Comment

30.10.2018 10:16:14

Model Name

Relational_1

Table Name

CARGO

Functional Name Abbreviation

CARGO

Classification Type Name Object Type Name MV Prebuilt MV Query

Description Notes

Number Of Columns Number Of Rows Min. Number Of Rows Max. Expected Number Of Rows Expected Growth Growth Interval

3 0 9999999 0 0 Year

Columns

No

Column Name

PK FK M

1 id_cargo

P

2 nombre_cargo

3 EMPLEADOS_id_empleado

F

DT kind

Data Type

Y NUMERIC (5)

LT

Y VARCHAR (30)

LT

Y VARCHAR (30 CHAR)

LT

Domain Name

Formula (Default Value)

Security Abbreviation

Indexes

Index Name

StateFunctional Spatial

CARGO_PK

Expression

PK

Column Name id_cargo

Sort Order ASC

Foreign Keys (referring to)

Name

Refering To

CARGO_EMPLEADOS_FK EMPLEADOS

MandatoryTransferable Y

Y

In Arc

Columns

Referred Columns

EMPLEADOS_id_empleado id_empleado

Delete Rule

Table Name

DEPARTAMENTOS

Functional Name Abbreviation

DEPARTAMENTOS

Classification Type Name Object Type Name MV Prebuilt MV Query

Description Notes

Number Of Columns

4

Number Of Rows Min.

0

Number Of Rows Max. Expected Number Of Rows

9999999 0

Expected Growth Growth Interval

0 Year

Columns

No

Column Name

PK FK M

1 id_departamento

P

2 nombre_departamento

DT Domain kind Name

Data Type

Y NUMERIC (5)

Formula (Default Security Abbreviation Value)

LT

Y VARCHAR LT (30) F Y VARCHAR (30 LT CHAR)

3 EMPLEADOS_id_empleado 4 EMPLEADOS_id_empleado1

F Y VARCHAR (30 LT CHAR)

Indexes

Index Name DEPARTAMENTOS_PK

StateFunctionalSpatial PK

Expression

Column Name id_departamento

Sort Order ASC


In Mandat Transfera Ar Columns ory ble c DEPARTAMENTOS_EMPLEAD EMPLEAD Y Y EMPLEADOS_id_empl OS_FK OS eado DEPARTAMENTOS_EMPLEAD EMPLEAD Y Y EMPLEADOS_id_empl OS_FKv2 OS eado1 Name

Refering To

Table Name

EMPLEADOS

Functional Name

EMPLEADOS

Abbreviation Classification Type Name Object Type Name MV Prebuilt MV Query

Description Notes

Number Of Columns Number Of Rows Min. Number Of Rows Max. Expected Number Of Rows Expected Growth Growth Interval

12 0 9999999 0 0 Year

Referred Columns id_emple ado id_emple ado

Delet e Rule

Columns

No

Column Name

Formula DT Domain (Default SecurityAbbreviation kind Name Value) Y VARCHAR LT (30 CHAR)

PK FK M Data Type

1 id_empleado

P

2 p_nombre

Y VARCHAR LT (30 CHAR)

3 s_nombre

VARCHAR LT (30 CHAR)

4 p_apellido


5 s_apellido

VARCHAR LT

6 estadoCivil


7 fecha_nacimiento

Y Date

LT

8 fecha_ingreso

Y Date

LT

9 sexo


10 salario

Y NUMERIC LT (5) VARCHAR LT (30 CHAR)

11 correo 12 EMPLEADOS_id_empleado

F Y VARCHAR LT (30 CHAR)

Indexes

Index Name EMPLEADOS_PK

StateFunctionalSpatial PK

Expression

Column Name id_empleado

Sort Order ASC


In Delet Mandato Transferab Referred Ar Columns e ry le Columns c Rule EMPLEADOS_EMPLEADO EMPLEAD Y Y EMPLEADOS_id_empl id_emplea S_FK OS eado do Name

Refering To

Foreign Keys (referred from)

Name

CARGO_EMPLEADOS_FK

In Mandat Transfera Referred From Ar ory ble c CARGO

Columns

Referred Columns

Y

Y

EMPLEADOS_id_em id_emple pleado ado

DEPARTAMENTOS_EMPLEA DEPARTAME DOS_FK NTOS

Y

Y


DEPARTAMENTOS_EMPLEA DEPARTAME DOS_FKv2 NTOS

Y

Y

EMPLEADOS_id_em id_emple pleado1 ado

EMPLEADOS_EMPLEADOS_F EMPLEADOS K

Y

Y


Dele te Rule

5. CONCLUSIONES

-El esquema lógico es una fuente de información para el diseño físico. -El diseño lógico es el proceso de construir un esquema de la información que utiliza la empresa, basándose en un modelo conceptual de base de datos específico. -El diseño físico es el proceso de producir la descripción de la implementación de la base de datos en memoria secundaria: estructuras de almacenamiento y métodos de acceso que garanticen un acceso eficiente a los datos. -El propósito del diseño físico es describir cómo se va a implementar físicamente el esquema lógico obtenido en la fase anterior. Concretamente, en el modelo relacional

6. BIBLIOGRAFIA

Modelado Relacional y Normalización Sosa Flores, M. & López Vázquez, M. (2007) Diseño de bases de datos relacionales. Córdoba, AR: El Cid Editor. Pág. 20-85. Recuperado de: http://bibliotecavirtual.unad.edu.co:2460/lib/unadsp/detail.action?docID=3175111& query=Dise%C3%B1o%20de%20bases%20de%20datos%20relacionales . Chicano, Tejada, Ester. Utilización de las bases de datos relacionales en el sistema de gestión y almacenamiento de datos: UF0348, IC Editorial, 2013. ProQuest Ebook Central, pág. 87-110. Recuperado de: https://bibliotecavirtual.unad.edu.co:2538/lib/unadsp/reader.action?ppg =

Desarrollo entidad relacion bases de datos basico-colaborativo2

Recommend Documents