Diferencia entre revisiones de «Mod BD UD3 Deseño Lóxico»
Línea 95: | Línea 95: | ||
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. | 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 | + | 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) == | == Primeira forma normal (1FN) == |
Revisión del 14:48 20 ago 2022
Sumario
- 1 Modelo lóxico de datos: metodoloxía
- 2 Modelo relacional: terminoloxía e características
- 3 Paso do diagrama E-R ao modelo relacional
- 4 Linguaxes relacionais
- 5 Normalización de modelos relacionais: dependencias funcionais; formas normais
- 6 Outras formas normais
- 7 Xustificación da desnormalización
- 8 Créditos e referencias
- 9 Boletíns
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
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 explicación máis detallada e algúns 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 explicación máis detallada e algúns 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:
SELECT s.theater
FROM schedule s, movie m
WHERE s.title = m.title AND m.director = “Bertolucci”
É 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 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 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:
NIF | Nome | Primeiro Apelido | Segundo Apelido | Teléfono |
---|---|---|---|---|
11111111H | María Xosé | López | Pérez | 666321555 677876432 |
123222333V | Brais | García | Xermade | 611222333 981333222 982444333 |
39653802P | Alba | Pereira | Pereira | 912300141 |
Unha primeira solución para alcanzar a 1FN consiste en atomizar o atributo Teléfono do seguinte modo:
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:
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 |
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:
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
Cod.Libro | Cod.tenda | Cantidade |
---|---|---|
479 | 12 | 3 |
322 | 1 | 1 |
377 | 12 | 4 |
873 | 9 | 5 |
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:
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 |
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 |
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 forma normal de Boyce-Codd (FNBC)
- a cuarta forma normal (4FN)
- a quinta forma normal (5FN)
- a forma normal de dominio/clave (DKNF)
- a 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 rendimento. E a desnormalización é a duplicación intencionada de columnas en varias tablas supoñendo un aumento da redundancia de datos.