diff --git a/Analisis III/Analisis 3 - Entrega.pdf b/Analisis III/Analisis 3 - Entrega.pdf index e667977..067a8f4 100644 Binary files a/Analisis III/Analisis 3 - Entrega.pdf and b/Analisis III/Analisis 3 - Entrega.pdf differ diff --git a/Analisis III/entregaanalisis.html b/Analisis III/entregaanalisis.html index 178c4bb..86410de 100644 --- a/Analisis III/entregaanalisis.html +++ b/Analisis III/entregaanalisis.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - + Analisis 3 - Entrega @@ -201,27 +201,28 @@

Table of Contents

-
-

1. Narrativa

+
+

1. Narrativa

La creación de este sistema surge como una herramienta que pueda servir de intermediario para que los usuarios puedan contactar de manera rápida y efectiva con distintos profesionales que se encarguen de brindar servicios, tales como: Electricista, gasista, plomero, etc. @@ -244,8 +245,8 @@ Una vez culminado el servicio por parte del profesional, el usuario podrá evalu

-
-

2. Analisis de Entidad-Relacion

+
+

2. Analisis de Entidad-Relacion

En este apartado se realizará un análisis exhaustivo sobre las distintas entidades que forman parte de la aplicación que @@ -256,8 +257,8 @@ sistema desde otro punto de vista.

-
-

3. Entidades Identificadas

+
+

3. Entidades Identificadas

  1. Profesionales
    2. @@ -278,7 +279,13 @@ sistema desde otro punto de vista.
  2. Cambios
  3. Administradores-Cambios
  4. Categorias
    5. - +
+
+
+
+

4. Visiones

+
+
  1. Se sabe que para los profesionales tendrán un código único que los identifique, los mismos podrán realizar muchas publicaciones al mismo tiempo, además tendrán un email y teléfonos únicos de contacto, tendrán la posibilidad de confirmar o rechazar los pre-Contratos generados por los usuarios interesados en dicha publicación.
  2. Los usuarios tendrán un DNI, que los identificará inequívocamente del resto, también contarán con un email y teléfono de contacto únicos.
  3. Las categorías contarán con una descripción única, que permitirán saber de que tipo es el servicio que se brindará.
    4. @@ -293,9 +300,9 @@ sistema desde otro punto de vista.
-
-

4. Codigo Sql

-
+
+

5. Codigo Sql

+
        create database App_Servicios;
 use App_Servicios;
@@ -403,10 +410,6 @@ Num_Comprobante int int foreign key references Profesionales (Num_Profesional),
 Num_Usuario int foreign key references Usuarios (Num_Usuario),
 Num_Publicacion int foreign key references Publicaciones (Num_Publicacion),
-
-6. Diagrama Pata de gallo
-
-7. Diagrama de clases
 Num_Pre_Contrato int foreign key references Pre_Contratos (Num_Pre_Contrato),
 Fecha_Generacion datetime not null,
 );
@@ -437,19 +440,19 @@ Lugar nvarchar (50)
-
-

5. Diagrama Pata de gallo

-
+
+

6. Diagrama Pata de gallo

+
-
+

master - proyecto_analisis3 - dbo.png

-
-

6. Marco Teorico Normalizacion

-
+
+

7. Marco Teorico Normalizacion

+

La normalización es un proceso fundamental en el diseño de bases de datos que tiene como objetivo reducir la redundancia y mejorar la integridad de los datos. Este proceso implica organizar los datos en tablas y columnas para asegurar que las dependencias entre datos estén correctamente definidas y las anomalías de actualización se minimicen. Las formas normales (NF) son los estándares utilizados para evaluar el nivel de normalización de una base de datos.

@@ -458,9 +461,9 @@ La normalización es un proceso fundamental en el diseño de bases de datos que A continuación, desarrollaremos las cinco formas normales (1FN, 2FN, 3FN, 4FN y 5FN) aplicadas a nuestro proyecto para poder tener una visión más práctica de lo que las mismas implican.

-
-

6.1. Primera Forma Normal (1FN)

-
+
+

7.1. Primera Forma Normal (1FN)

+

La Primera Forma Normal establece que los datos deben estar organizados en tablas de manera que cada columna contenga valores atómicos, y cada fila sea única.

@@ -481,9 +484,9 @@ Por ejemplo, la tabla `Profesionales` tiene columnas con valores indivisibles y
-
-

6.2. Segunda Forma Normal (2FN)

-
+
+

7.2. Segunda Forma Normal (2FN)

+

La Segunda Forma Normal requiere que la base de datos cumpla con 1FN y que todos los atributos no clave dependen completamente de la clave primaria. Esto significa que no debe haber dependencias parciales en una tabla. Las tablas como `Credenciales` cumplen con esta forma normal, ya que todos sus atributos dependen completamente de la clave primaria `Numcredencial`.

@@ -501,9 +504,9 @@ La Segunda Forma Normal requiere que la base de datos cumpla con 1FN y que todos
-
-

6.3. Tercera Forma Normal (3FN)

-
+
+

7.3. Tercera Forma Normal (3FN)

+

La Tercera Forma Normal requiere que la base de datos cumpla con 2FN y que no haya dependencias transitivas, es decir, los atributos no clave deben depender solo de la clave primaria y no de otros atributos no clave. Las tablas como `Publicaciones` cumplen con esta forma normal, ya que todos sus atributos dependen directamente de la clave primaria `NumPublicacion`.

@@ -522,9 +525,9 @@ La Tercera Forma Normal requiere que la base de datos cumpla con 2FN y que no ha
-
-

6.4. Cuarta Forma Normal (4FN)

-
+
+

7.4. Cuarta Forma Normal (4FN)

+

La Cuarta Forma Normal se ocupa de las dependencias multivaluadas. Una tabla está en 4FN si está en 3FN y no tiene dependencias multivaluadas no triviales. En nuestro caso las tablas no presentan dependencias multivaluadas no triviales, lo que significa que cumplen con esta forma normal. Por ejemplo, la tabla `AdministradoresPermisos` maneja correctamente las relaciones muchos a muchos sin introducir redundancias indebidas.

@@ -539,9 +542,9 @@ La Cuarta Forma Normal se ocupa de las dependencias multivaluadas. Una tabla est
-
-

6.5. Quinta Forma Normal (5FN)

-
+
+

7.5. Quinta Forma Normal (5FN)

+

La Quinta Forma Normal requiere que la base de datos esté en 4FN y que cualquier dependencia de unión no trivial esté implícita en las claves candidatas. Esto significa que una tabla no debe poder descomponerse en dos o más tablas más pequeñas que se puedan unir sin pérdida de información.

@@ -565,22 +568,22 @@ Por ejemplo, la tabla `Contratos` no puede descomponerse sin pérdida de informa
-
-

7. Diagrama de clases

-
+
+

8. Diagrama de clases

+
-
+

DiagramaDeCLases.png

-
-

8. Diagrama Entidad-Relacion

-
+
+

9. Diagrama Entidad-Relacion

+
-
-

D.E.R.jpg +

+

D.E.R.jpg

@@ -588,7 +591,7 @@ Por ejemplo, la tabla `Contratos` no puede descomponerse sin pérdida de informa

Author: Grupo 1

-

Created: 2024-07-07 dom 19:42

+

Created: 2024-07-07 dom 20:02

diff --git a/Analisis III/entregaanalisis.org b/Analisis III/entregaanalisis.org index 58d35b9..20ed597 100644 --- a/Analisis III/entregaanalisis.org +++ b/Analisis III/entregaanalisis.org @@ -46,6 +46,7 @@ sistema desde otro punto de vista. 17. Administradores-Cambios 18. Categorias +* Visiones 1. Se sabe que para los profesionales tendrán un código único que los identifique, los mismos podrán realizar muchas publicaciones al mismo tiempo, además tendrán un email y teléfonos únicos de contacto, tendrán la posibilidad de confirmar o rechazar los pre-Contratos generados por los usuarios interesados en dicha publicación. 2. Los usuarios tendrán un DNI, que los identificará inequívocamente del resto, también contarán con un email y teléfono de contacto únicos. 3. Las categorías contarán con una descripción única, que permitirán saber de que tipo es el servicio que se brindará. @@ -166,10 +167,6 @@ Num_Comprobante int foreign key references Comprobantes_Pago (Num_Comprobante) n Num_Profesional int foreign key references Profesionales (Num_Profesional), Num_Usuario int foreign key references Usuarios (Num_Usuario), Num_Publicacion int foreign key references Publicaciones (Num_Publicacion), - -6. Diagrama Pata de gallo - -7. Diagrama de clases Num_Pre_Contrato int foreign key references Pre_Contratos (Num_Pre_Contrato), Fecha_Generacion datetime not null, ); @@ -283,5 +280,5 @@ create table Contratos( [[./DiagramaDeCLases.png]] * Diagrama Entidad-Relacion -#+attr_html: :width 1500px +#+attr_html: :width 1000px [[./D.E.R.jpg]]