Ver el código de «Mod BD UD3 Deseño Lóxico»

= Modelo lóxico de datos: metodoloxía =

= Modelo relacional: terminoloxía e características =

== Claves primarias e alleas ==

= Paso do diagrama E-R ao modelo relacional =
Pola súa extensión adicaremoslle unha sección aparte ó [[paso do diagrama E-R ao modelo relacional]].

= Linguaxes relacionais  =

[[File:Alxebra_e_calculo_relacional_son_equivalentes.png|frame|right|Cálculo e alxebra relacional son equivalentes con correspondencia entre as súas operacións]] 

As linguaxes relacionais operan sobre conxuntos de tuplas, é dicir, non son linguaxes navegacionais (que manipulan rexistros, como C#, Java, etc.) senón de especificación.

Divídense en dous tipos:
; Alxebraicos (álxebra relacional)
: os cambios de estado especifícanse mediante operacións, con operandos como relacións e o seu resultado é outra relación.
; Predicativos (cálculo relacional):
: os cambios de estado especifícanse mediante predicados que definen o estado obxectivo sen indicar as operacións que hai que realizar para chegar ao mesmo. Divídense en dous subtipos.
:* orientados a tuplas.
:* orientados a dominios.

== Álxebra relacional ==
A '''Álxebra Relacional''' ('''AR''') constitúe a dinámica do modelo relacional (MR), foi definida por Codd en 1972, está composta por unha colección de operadores que toman relacións como operandos e devolven relacións como resultado (clausura relacional). Os operandos son relacións, e non conxuntos arbitrarios; as operacións baseadas na teoría de conxuntos están adaptadas ás relacións que son un tipo especial de conxuntos.
Sexan R1, R2, ..., Ri e Rr relacións e OP un operador do AR, unha operación consiste en aplicar OP a(s) relación(s) R1, ... Ri, obténdose Rr: OP(R1 ... Ri) = Rr.

Ao ser o resultado da operación outra relación, cúmprese a propiedade de cerre, é dicir, si OP1....OPn representan operadores, cúmprese: OPn  ( ... (OP1 ( R) ) ) = Rr.
Nesta propiedade de clausura relacional permítese aplicar unha operación tras outra establecéndose que a saída dunha operación pode ser entrada (operando) doutra e as expresións poden aniñarse formando a súa vez unha expresión con operandos que conteñen a súa vez outra expresión da álxebra en vez de nomes de relación.
Sexan R1, R2, R3, relacións de tipos compatibles, podendo indicar:
    • Unha única expresión dando lugar a expresións aniñadas: R Ç ( S È T ).
    • Varias expresións establecendo relacións intermedias con nome.
    • A ¬ S È T.
    • B ¬ R Ç A.

=== Operadores do álxebra relacional ===
Os operadores do Alxebra Relacional (AR) son 8.

Pódense clasificar de tres formas diferentes.

Segundo a súa orixe:
* Procedentes da teoría de conxuntos:
:* unión (υ)
:* intersección ( )
:* diferenza (-)
:* produto cartesiano ( x )
* Relacionais especiais:
:* restrición
:* proxección
:* combinación
:* división.

Segundo a completitude da linguaxe:
* Primitivos: operadores esenciais que non poden obterse doutros (sen eles, o AR non sería unha linguaxe completa).
* Derivados: pódense obter aplicando varios dos operadores primitivos. Aínda que se pode prescindir deles, son útiles para simplificar moitas operacións habituais.

Segundo o número de operandos:
* Unarios: actúan sobre unha única relación.
:* SELECT (símbolo: σ)
:* PROJECT (símbolo: π)
:* RENAME (símbolo: ρ)

* Binarios: o operador ten dúas relacións como operandos.
:* JOIN
:* DIVISION

Podes atopar [https://www.w3schools.in/dbms/relational-algebra explicación máis detallada] e algúns [https://www.guru99.com/relational-algebra-dbms.html exemplos] para comprender o seu funcionamento,

=== Correspondencia da álxebra relacional coa linguaxe de consulta SQL ===

== Cálculo relacional ==
O '''Cálculo Relacional''' ('''CR''') foi proposto por Codd, como alternativa á álxebra relacional que resultaba demasiado matemática para o usuario final, co fin de obter unha linguaxe que se parecera máis as linguaxes de programación.

A diferenza entre ambas é que mentres a álxebra relacional ofrece o conxunto de operacións para construír a relación que se quere obter a partir dunhas relacións dadas, indica o procedemento que se debe utilizar para obter o resultado;  o cálculo relacional ofrece unha notación para indicar como debe ser a relación resultado en función dunhas relacións determinadas, e dicir, o cálculo só plantexa o problema (só é preciso indicar o resultado que se quere obter).

Existen dous tipos de cálculo relacional que adáptanse ao Cálculo de Predicados de Primeira Ode, no que se basean, para crear una Linguaxe de Consultas para Bases de Datos Relacionais (BDR):
* O proposto por Codd, en 1972, chamado cálculo relacional orientado á tupla (CRT), no mesmo, unha variable interprétase como si representase as tuplas dunha relación.
* O proposto por Lacroix e Pirotte, en 1977, chamado cálculo relacional orientado ao dominio, no que unha variable interprétase como si representase os valores dun dominio.

Podes atopar [https://www.w3schools.in/dbms/relational-calculus explicación máis detallada] e algúns [https://cseweb.ucsd.edu/classes/fa19/cse132A-a/slides/relational-calculus.pdf exemplos] para comprender o seu funcionamento, 

=== Correspondencia do cálculo relacional coa linguaxe de consulta SQL ===
Existe unha relación entre o cálculo relacional é a linguaxe SQL. Por exemplo no enuncado:
 "Cines que proxectan películas de Bertolucci"

En SQL:
<syntaxhighlight lang="sql">
SELECT s.theater
FROM schedule s, movie m
WHERE s.title = m.title AND m.director = “Bertolucci”
</syntaxhighlight>

É a túpla de cálculo relacional :
 { t: theater | ∃ s ∈ schedule ∃ m ∈ movie [ t(theater) = s(theater) ∧ s(title) = m(title) ∧ m(director) = Bertolucci ] }

Podes consultar [https://cseweb.ucsd.edu/classes/fa19/cse132A-a/slides/relational-calculus.pdf este exemplo e outros] a partires da diapositiva 23.

== Diferenzas entre a álxebra e o cálculo relacional ==
As diferenzas entre a álxebra e o cálculo relacional son totalmente equivalentes, por cada expresión do cálculo relacional existe unha expresión equivalente da álxebra relacional e viceversa, e ambas son a parte dinámica do modelo relacional.

= Normalización de modelos relacionais: dependencias funcionais; formas normais =
Codd fixo a definición dunhas normas que evitan as redundancias de información nunha solución relacional cando son aplicadas. A técnica de seguemento de esas normas é coñecida como '''normalización''', e consiste en levar todas as relacións a determinados estados chamados formas normales.

 O inglés Edgar Frank "Ted" Codd é o pai das bases de datos relacionales. A mediados dos anos oitenta aportou as definicións coñecidas como “as 12 regras de Codd“ (aínda que son trece, numeradas do cero ó doce) que todo SGBDR debe cumplir. Buscaba revertir a tendencia dos fabricantes de SGBDR a obviar elementos fundamentais da súa proposta de modelo relacional,Algunhas delas son moi complexas de seguir e son máis estudadas desde o punto de vista teórico; pero a mera existencia das 12 regras supuxo unha declaración de intencións sobre o camiño que debía tomar o mundo das bases de datos.

Ímos ver a teoría cun exemplo, e podes atopar máis información en [https://www.w3schools.in/dbms/database-normalization w3schools]. 

== Primeira forma normal (1FN) ==
Unha relación está en primera forma normal (1FN) se todos os seus valores son atómicos; isto é, cada valor dos dominios de todos os atributos é único. 

No seguinte exemplo (clave primaria en '''grosa''') vemos un atributo, ''Teléfono'', que ten valores que no son repetitivos e non atómicos: 

{| class="wikitable"
|+Relación sen normalizar
! NIF
! Nome
! Primeiro Apelido
! Segundo Apelido
! Teléfono
|-
| 11111111H 
| María Xosé
| López
| Pérez 
| 666321555 <br/> 677876432
|-
| 123222333V
| Brais
| García
| Xermade
| 611222333 <br/> 981333222 <br/> 982444333
|-
| 39653802P
| Alba
| Pereira
| Pereira
| 912300141
|}

Unha primeira solución para alcanzar a 1FN consiste en atomizar o atributo ''Teléfono'' do seguinte modo:

{| class="wikitable"
|+Relación en 1FN
! NIF
| Nome
| Primeiro Apelido
| Segundo Apelido
| Teléfono
|-
| 11111111H 
| María Xosé
| López
| Pérez 
| 666321555
|-
| 11111111H 
| María Xosé
| López
| Pérez
| 677876432
|-
| 123222333V
| Brais
| García
| Xermade
| 611222333
|-
| 123222333V
| Brais
| García 
| Xermade
| 981333222
|-
| 123222333V
| Brais
| García 
| Xermade
| 982444333
|-
| 39653802P
| Alba
| Pereira
| Pereira
| 912300141
|}

Esta solución implica unha forte redundancia (''Nome'', '' e '' repítense por cada teléfono), e invalida a ''NIF'' como clave primaria, obrigando a ampliar dita clave primaria co atributo ''Teléfono''. Por ese motivo proponse unga solución máis elaborada consistente en dividir a relación orixinal en dúas (unha coas persoas e outra cos teléfonos), vinculándoas mediante os valores da clave primaria orixinal:

{| class="wikitable"
|+Relación en 1FN
! NIF
| Nome
| Primeiro Apelido
| Segundo Apelido
|-
| 11111111H 
| María Xosé
| López
| Pérez 
|-
| 11111111H 
| María Xosé
| López
| Pérez
|-
| 123222333V
| Brais
| García
| Xermade
|-
| 123222333V
| Brais
| García 
| Xermade
|-
| 123222333V
| Brais
| García 
| Xermade
|-
| 39653802P
| Alba
| Pereira
| Pereira
|}

{| class="wikitable"
|+Relación en 1FN
! NIF
! Teléfono
|-
| 11111111H 
| 666321555
|-
| 11111111H 
| 677876432
|-
| 123222333V
| 611222333
|-
| 123222333V
| 981333222
|-
| 123222333V
| 982444333
|-
| 39653802P
| 912300141
|}


La 1FN é parte da definición do modelo relacional polo que o seu cumprimento é obrigatorio.

== Segunda forma normal (2FN) ==
Una relación está en segunda forma normal (2FN) se cumpre que:
* Está en 1FN.
* Todos os atributos que non forman parte da clave primaria dependen dela por completo.

A relación seguinte ilustra o stock dunha librería. A clave primaria está composta por dous atributos (''Código de libro'' e ''Código de tenda''), pero o atributo ''Enderezo'' non depende de toda a clave, se non únicamente do atributo ''Código de tenda''. Por ese motivo repítese o enderezo da tenda 12, coa conseguinte redundancia de información:

{| class="wikitable"
|+Relación en 1FN mais non en 2FN
! Cod. Libro
! Cod. Tenda
! Cantidade
! Enderezo
|-
| 479 
| 12
| 3
| Praza de armas, 3
|-
| 322 
| 1
| 8
| Estrada de castela,12
|-
| 377 
| 12
| 4
| Praza de armas, 3
|-
| 873
| 9
| 5
| Rúa real, 5
|}

Neste caso o proceso de normalización obriga a dividir a relación en dúas, unha coa información da tenda e outra coa do ''stock''


{| class="wikitable"
|+Relaciones en 2FN
! Cod.Libro
! Cod.tenda
! Cantidade
|-
|479
|12
|3
|-
|322
|1
|1
|-
|377
|12
|4
|-
|873
|9
|5
|}

{| class="wikitable"
|+Relaciones en 2FN
!Cod.tenda
!Enderezo
|-
|12
|Praza de armas, 3
|-
|1
|Estrada de Castela, 12
|-
|9
|Rúa real, 5
|}

Nótese que a 2FN só se pode violar se a clave primaria está composta por máis dun atributo, polo que toda relación en 1FN na que a súa clave primaria esté formada por un só atributo tamén está en 2FN.

== Tercera forma normal (3FN) ==
Unha relación está en terceira forma normal (3FN) se: 
* Está en 2FN.
* Todos os atributos que non forman parte da clave primaria son independentes entre sí; isto é, non dan información sobre outros atributos da relación.

O seguiente exemplo ilustra unha relación con información sobre empregados. Todos os atributos dependen directamente da clave primaria ''Código de empregado'' excepto ''Nome de departamento'', que depende de ''Código de departamento'': 

{| class="wikitable"
|+Relación en 2FN, pero no en 3FN
!Cód. emp. 
|Nome 
|Apelidos 
|Enderezo 
|Cód. dpto. 
|Nome dpto. 
|Data nac.
|-
|27 
|Antía 
|Menéndez Xarmolo 
|Rúa Telleiras, 5 
|3 
|Producción 
|03/01/1983
|-
|249 
|David 
|Ramírez Blanco 
|Rúa María, 7 
|2 
|Informática 
|15/05/1973
|-
|153 
|Xurxo 
|Peleteiro Galiano 
|Rúa Piano, 1 
|5 
|RRHH 
|14/02/1979
|-
|191 
|Ruth 
|Lázaro Cardenal 
|Rúa Dolores, 9 
|3 
|Producción
|19/03/2003
|}


{| class="wikitable"
|+Relación en 3FN
!Cód. emp. 
|Nome 
|Apelidos 
|Enderezo 
|Cód. dpto. 
|Data nac.
|-
|27 
|Antía 
|Menéndez Xarmolo 
|Rúa Telleiras, 5 
|3 
|03/01/1983
|-
|249 
|David 
|Ramírez Blanco 
|Rúa María, 7 
|2 
|15/05/1973
|-
|153 
|Xurxo 
|Peleteiro Galiano 
|Rúa Piano, 1 
|5 
|14/02/1979
|-
|191 
|Ruth 
|Lázaro Cardenal 
|Rúa Dolores, 9 
|3 
|19/03/2003
|}

{| class="wikitable"
|+Relaciones en 3FN
!Cód. dpto.
|Nome dpto.
|-
|3 
|Producción
|-
|2 
|Informática
|-
|5 
|RRHH
|}

= Outras formas normais=
Codd definíu inicialmente as regras relativas as tres primeiras formas normais, que todo diseño relacional é aconsellable que cumpla. Máis adiante ampliouse a teoría da normalización con:
* a [https://es.wikipedia.org/wiki/Forma_normal_de_Boyce-Codd forma normal de Boyce-Codd (FNBC)]
* a [https://es.wikipedia.org/wiki/Cuarta_forma_normal cuarta forma normal (4FN)]
* a [https://es.wikipedia.org/wiki/Quinta_forma_normal quinta forma normal (5FN)]
* a [https://es.wikipedia.org/wiki/Forma_normal_de_dominio/clave forma normal de dominio/clave (DKNF)]
* a [https://adgarza.blogspot.com/2019/03/normalizacion-de-bases-de-datos-parte-6.html sexta forma normal (6FN)] 

Todas elas forzan restriccións que fan a súa aplicación pouco recomendable en moitos entornos reales, quedando máis recomendables para o seu coñecemento e aplicación no campo teórico.

= Xustificación da desnormalización =
As reglas de normalización non teñen en cosideración o rendemento. A premisa das regras de normalización é que as sentenzas de SQL poden recuperar a información unindo as dúas tablas; o problema é que nalgúns casos podense producir problemas de rendimento como resultado dunha normalización. 

Por exemplo, algunhas consultas de usuario poden ver datos que están en varias tablas relacionadas; o resultado implica demasiadas unións. A medida que crece o número de tablas, os custes de acceso poden aumentar segundo o tamaño das tablas, os índices disponibles, etc. 

Porén, '''nalgúns casos''' é preciso considerar a '''desnormalización para mellorar o rendemento'''. A '''desnormalización''' é a '''duplicación intencionada de columnas en varias tablas supoñendo un aumento da redundancia de datos'''.

= Créditos e referencias =
* [http://www3.uji.es/~mmarques/f47/teoria/tema7.pdf Diseño lógico]
* [https://es.wikipedia.org/wiki/%C3%81lgebra_relacional Álgebra relacional]
* [https://es.wikipedia.org/wiki/C%C3%A1lculo_relacional Cálculo relacional]
* [https://www.cs.us.es/blogs/bd2013/files/2013/09/BD-Tema-4.pdf Normalización]
* [https://www.ibm.com/docs/es/db2-for-zos/11?topic=design-database-denormalization Desnormalización]

= Boletíns =
* [[Tarefas de transformación do modelo Entidade-Relación a modelo Relacional]]
* [[Tarefas de álxebra e cálculo relacional]]