|
|
| (11 revisiones intermedias por el mismo usuario no mostrado) |
| Línea 11: |
Línea 11: |
| | {{#widget:Slides}} | | {{#widget:Slides}} |
| | <div class="slides layout-regular template-default"> | | <div class="slides layout-regular template-default"> |
| − | <div id=parrafo>
| + | |
| | + | |
| | + | |
| | + | |
| | + | |
| | <div id=parrafo> | | <div id=parrafo> |
| | ===BASES DE DATOS: Introducción=== | | ===BASES DE DATOS: Introducción=== |
| Línea 30: |
Línea 34: |
| | {{MRM_Puntos clave| | | {{MRM_Puntos clave| |
| | El diseño de la base de datos se debería de hacer solo una vez y modificarlo pocas veces durante su vida}} | | El diseño de la base de datos se debería de hacer solo una vez y modificarlo pocas veces durante su vida}} |
| − | ===Sistema de información===
| |
| − | <br />
| |
| − | {{MRM_Definicion|Title=Qué es un sistema|
| |
| − | Conjuntos de elementos realcionados que pretenden un determinado objetivo
| |
| − | }}
| |
| − | {{MRM_Definicion|Title=Qué es un sistema de información|
| |
| − | Es la parte lógica o de información de un determinado sistema.<br />
| |
| − | Nos interesa especialemente por que va a ser la parte que vamos a estudiar para automatizar o informatizar
| |
| − | }}
| |
| − | {{MRM_Definicion|Title=Parte dinámica/estática|
| |
| − | Dentro de un sistema que vayamos a automatizar, tendremos elementos dinámicos que corresponden a las acciones o programación y una parte estática que corresponden a los datos que queremos almacenar en nuestro sistema
| |
| − | }}
| |
| | ===Ciclo en el desarrollo de una base de datos=== | | ===Ciclo en el desarrollo de una base de datos=== |
| | <br /> | | <br /> |
| − | Hay tres niveles como podemos ver en la imagenive | + | Hay tres niveles como podemos ver en la imagen |
| − | {{MRM_Definicion|Title=Niveles en el desarrollo de una base de datos|
| + | |
| − | 1.-Nivel conceptual
| + | |
| − | La concepción del sistema tal como se puede percibir por las personas
| + | |
| − | Lo que realmente ocurre en el funcionamiento cotidiano
| + | |
| − | 2.-Nivel Lógico
| + | |
| − | Identificar esa parte del sistema que se va a poder automatizar
| + | |
| − | Concretar la manera como lo vamos a hacer
| + | |
| − | Especificar ya elementos lógicos para ser automatizados
| + | |
| − | 3.-Nivel Físico
| + | |
| − | Usando una herramienta o tecnología concreta
| + | |
| − | Transformar los elementos lógicos a código entendible por el computador
| + | |
| − | }}
| + | |
| − | [[imagen:ciclo_vida_bd.png]]
| + | |
| − | | + | |
| − | ===Nivel Conceptual===
| + | |
| − | *Corresponde a obtener las especificaciones del cliente
| + | |
| − | *En este nivel debemos establecer comunicación con el cliente y técnicos.
| + | |
| − | ;Cliente
| + | |
| − | Grupo de personas que saben mucho de su negocio, pero seguramente poco de tecnologías de desarrollo
| + | |
| − | ;Técnico
| + | |
| − | Persona/s que tienen (deben tener) un alto conocimiento de desarrollo técnico, pero seguramente saben poco del negocio que han de automatizar
| + | |
| − | ; Objetivo
| + | |
| − | Qué el grupo técnico tenga un conocimiento detallado del negocio y puedan desarrollar una aplicación que satisfaga
| + | |
| − | las necesidades del cliente<BR />
| + | |
| − | [[Imagen:especificacion1.png]]
| + | |
| − | ====Modelado conceptual====
| + | |
| − | <br />
| + | |
| − | {{MRM_Definicion|Title=Modelado|
| + | |
| − | Lo entederemos como un '''''lenguaje'''''<br 7>
| + | |
| − | que nos va a permitir describir datos .}}
| + | |
| − | *Serán los datos que queremos almacener de un determinado universo del discurso.
| + | |
| − | *Usaremos el Modelo Entidad/Relación
| + | |
| − | *también conocido como modelo Entidad interrelacion o modelo de chen}}
| + | |
| − | {{MRM_Definicion|Title=El diagrama entidad-interrelación (DEI)|
| + | |
| − | Este diaglama es un modelado que permite representar la estática del modelo de datos entidad-interrelación mediante un lenguaje gráfico de definición de estructuras.}}
| + | |
| − | {{MRM_Definicion|Title=Elementos o lexemas de este lenguaje|
| + | |
| − | ;entidades
| + | |
| − | ;atributos
| + | |
| − | ;interrelaciónes entre entidades.
| + | |
| − | }}
| + | |
| − | | + | |
| − | ====Modelo Entidad/Relación====
| + | |
| − | *Es un modelo que nos va a permitir mostrar la parte estática del sistema
| + | |
| − | *Solo va a mostrar los elementos o '''''entidades''''' y las '''''relaciones''''' que ocurren ente ellos
| + | |
| − | | + | |
| − | =====Entidades=====
| + | |
| − | *Las entidades son esos elementos de los cuales queremos guardar información
| + | |
| − | | + | |
| − | {{MRM_Definicion|Title=Entidad|
| + | |
| − | El conjunto de elementos u objetos concretos o abstractos de los que se quiere almacenar información dentro de este sistema}}
| + | |
| − | [[Imagen:concepto_entidad.png]]
| + | |
| − | ;Representación gráfica
| + | |
| − | *Su representación es un rectángulo
| + | |
| − | *El nombre se especifica dentro del rectángulo
| + | |
| − | *Se suelen poner en singular
| + | |
| − | [[Imagen:entidad.png]]
| + | |
| − | *Una entidad va a representar un conjunto de elementos, por ejemplo la entidad '''''Alumno''''' representará varios alumnas
| + | |
| − | [[Imagen:entidad_conjunto.png]]
| + | |
| − | ;Tipos de entidades
| + | |
| − | {{MRM_Definicion|Title=Entidades débiles|
| + | |
| − | *Son entidades que dependen de otra para que existan o incluso para poderse identificar
| + | |
| − | *Se representan con un doble cuadrado
| + | |
| − | [[Archivo:Entidad_debil.png]]
| + | |
| − | }}
| + | |
| − | {{MRM_Definicion|Title=Tipos de debilidades|
| + | |
| − | ;Debilidad en existencia
| + | |
| − | *Para que exista un elemento de la entidad tiene que existir el elemento de la entidad con el que está relacionado
| + | |
| − | {{MRM_Ejemplo|Title=Debilidad en existencia|
| + | |
| − | *Supongamos el siguiente ejemplo
| + | |
| − | En una empresa que tiene '''''empleados''''' se quiere saber los '''''familiares'''''
| + | |
| − | de los empleados para por ejemplo tener acceso a las instalaciones
| + | |
| − | o acceder a determinadas promociones
| + | |
| − | Si un empleado dejara de serlo, claramente los familiares de ese empleado
| + | |
| − | ya no serían datos que a la empresa le interesara conocer
| + | |
| − | Aquí vemos la debilidad en existencia
| + | |
| − | [[Archivo:debilidad_existencia_emp_fam.png]]
| + | |
| − | }}
| + | |
| − | ;Debilidad en identificación
| + | |
| − | *Son entidades que dependen de otra para que existan o incluso para poderse identificar
| + | |
| − | *Se representan con un doble cuadrado
| + | |
| − | {{MRM_Ejemplo|Title=Debilidad en identificación|
| + | |
| − | *Es una debilidad más fuerte
| + | |
| − | *En ella para poder '''''identificar''''' un elemento de una entidad, necesitamos identificar previamente el elemento de la entidad con el que está relacionado
| + | |
| − | *Supongamos un ejemplo
| + | |
| − | En un hotel tenemos '''''plantas''''' (primero, segunda, ...)
| + | |
| − | cada planta tiene unas características y más atributos que nos interesa guardar
| + | |
| − | Las plantas tienen '''''habitaciones''''' que se identifican por
| + | |
| − | un número (de la 1 hasta el número de habitaciones que haya.
| + | |
| − | Está claro que para saber de qué habitación hablamos en un momento dado,
| + | |
| − | no podemos decir la habitacion 10, habrá que decir la habitación 10,
| + | |
| − | de la planta 2 o la que sea
| + | |
| − | Aquí vemos la debilidad en ''identificación'' ya que ''para identificar un elemento
| + | |
| − | de la entidad habitación, previamente necesitamos conocer el elemento de la entidad
| + | |
| − | '''''Planta''''' con el que está relacionado''.
| + | |
| − | Por supuesto que también es una debilidad en existencia,
| + | |
| − | ya que si desapareciera una planta, desaparecerían también las habitaciones.
| + | |
| − | [[Archivo:debilidad_identificacion_pla_hab.png]]
| + | |
| − | }}
| + | |
| − | | + | |
| − | ;Jerarquía entre entidades
| + | |
| − | *Como ya hemos estudiado en la herencia dentro de la programación orientada a objetos, puede ocurrir que una entidad se pueda especializar.
| + | |
| − | *Es decir que una entidad pueda ser de diferentes tipos, y ademas, cada uno de esos subtipos tengan atributos o relaciones de forma individual (no compartidos).
| + | |
| − | *En este caso podremos establecer una jerarquía
| + | |
| − | {{MRM_Definicion|Title=Jerarquia|
| + | |
| − | *Es una estructura de datos en la cual tenemos entidades que se especializan en subtimos
| + | |
| − | *Cada subtipo a de tener atributos y/o relaciones de forma individual (Si no fuera así sería suficiente con tener un atributo llamado tipo)
| + | |
| − | {{MRM_Ejemplo|Title=Jerarquía con atributos individuales|
| + | |
| − | Una editorial realiza '''''publicaciones'''''. Estas publicaciones pueden
| + | |
| − | ser libros en cuyo caso necesitamos conocer el autor principal
| + | |
| − | o también revistas, en cuyo caso necesitamos la tirada (número de ejmplares
| + | |
| − | de esa publicación)
| + | |
| − | [[Imagen:jerarquia_1.png]]
| + | |
| − | | + | |
| − | }}
| + | |
| − | {{MRM_Ejemplo|Title=Jerarquía con relaciones individuales|
| + | |
| − | En el ejemplo anterior además una '''''publicaciones''''' tiene subscriptores
| + | |
| − | [[Imagen:jerarquia_2.png]]
| + | |
| − | }}
| + | |
| − | {{MRM_Ejemplo|Title=Entidad con un atributo tipo, pero sin jerarquía|
| + | |
| − | [[Imagen:jerarquia_3.png]]
| + | |
| − | }}
| + | |
| − | | + | |
| − | }}
| + | |
| − | ;Concepto de agregación
| + | |
| − | | + | |
| − | =====Atributos=====
| + | |
| − | *Qué son
| + | |
| − | {{MRM_Definicion|Title=Atributos|
| + | |
| − | ;Son las características que queremos guardar de las entidades
| + | |
| − | *Van a permitir diferenciar una elemento de otro dentro de la entidad
| + | |
| − | *Se pueden representar de diferentes maneras, usaremos un cículo
| + | |
| − | [[Imagen:atributo.png]]
| + | |
| − | *Se une a la entidad con una línea
| + | |
| − | [[Imagen:atributo_entidad.png]]
| + | |
| − | }}
| + | |
| − | ;Tipos de atributos
| + | |
| − | {{MRM_Definicion|Title=Atributo Clave|
| + | |
| − | ;Hemos dicho que una entidad representa un conjunto de elementos
| + | |
| − | *Por definición un conjunto está formado por 0 o más elementos los cuales han de ser necesariamente diferenciables
| + | |
| − | *Aplicado a nuestro caso, quiere decir que hemos de poder diferenciar dos elementos cualesqueira de nuestro conjunto.
| + | |
| − | *Esto se consigue teniendo uno o más atributos que constituyan la clave, es decir que sus valores no se pueden repetir.
| + | |
| − | {{MRM_Ejemplo|Title=Representacion|
| + | |
| − | [[Archivo:atributo_clave.png]]<br />
| + | |
| − | *Otro caso:<br />
| + | |
| − | [[Archivo:atributo_clave2.png]]<br />
| + | |
| − | }}
| + | |
| − | | + | |
| − | }}
| + | |
| − | {{MRM_Definicion|Title=Atributo Compuesto|
| + | |
| − | *Es un atributo que a su vez está formado por más atributos
| + | |
| − | {{MRM_Ejemplo|Title=Representacion|
| + | |
| − | Se representa ligando con una flecha al atributo compuesto sus componentes
| + | |
| − | [[Archivo:atributo_compuesto.png]]<br />
| + | |
| − | }}
| + | |
| − | | + | |
| − | }}
| + | |
| − | {{MRM_Definicion|Title=Atributo Multivaluado|
| + | |
| − | *Ocurre cuando un atributo puede tomar varios valores.
| + | |
| − | {{Nota|No confundir con el hecho de que pueda tomar un valor
| + | |
| − | entre una lista de valores posibles}}
| + | |
| − | {{MRM_Ejemplo|Title=Representación|
| + | |
| − | ;Se representa con un doble círculo
| + | |
| − | Un alumno puede hablar varios idiomas
| + | |
| − | [[Archivo:atributo_multivaluado1.png]]
| + | |
| − | Un alumno estudiante puede tener varios estudios
| + | |
| − | [[Archivo:atributo_multivaluado2.png]]
| + | |
| − | Un alumno estudiante puede tener varios estudios pero solo nos interesa el de mayor nivel entre (ESO, BASH, CICLO, CERTIFICADO, GRADO)
| + | |
| − | [[Archivo:atributo_multivaluado3.png]]
| + | |
| − | }}
| + | |
| − | }}
| + | |
| − | | + | |
| − | | + | |
| − | {{MRM_Definicion|Title=Atributo Derivado
| + | |
| − | *Es aquel atributo cuyo valor no necesitamos almacenarlo, ya que lo podemos calcular a partir de los valores de otro/s atributos y/o valores del sistema.
| + | |
| − | {{MRM_Ejemplo|Title=Representación|
| + | |
| − | ;Se representa con líneas discontinuas en el círculo
| + | |
| − | De un alumno se quiere saber su fecha de nacimiento y su edad
| + | |
| − | La edad la podremos calcular a partir de la fecha de nacimiento
| + | |
| − | y de la fecha actual que siempre podremos obtener del sistema
| + | |
| − | [[Archivo:atributo_derivado.png]]
| + | |
| − | | + | |
| − | | + | |
| − | }}
| + | |
| − | ;Atributos de la relación
| + | |
| − | {{MRM_Definicion|Title=Atributo de la relación|
| + | |
| − | *Hay muchas ocasiones en las cuales las propiedades o características se establecen entre dos entidades que se relacionan
| + | |
| − | *Pero en realidad no pertenecen en particular a ninguna de ellas, sino que son características que toman valor cuando se establece la relación entre dos elementos relacionados
| + | |
| − | *En este caso diremos que el atributo es de la relación.
| + | |
| − | {{MRM_Ejemplo|Title=Atributos de la relación|
| + | |
| − | Un programador trabaja en un proyecto con un determinado cargo
| + | |
| − | el programador puede desempeñar diferentes cargos:
| + | |
| − | (analista, programador, diseñador de software, maquetador)
| + | |
| − | Este atributo toma valor cuando un ''programador'' '''trabaja''' en un ''proyecto''
| + | |
| − | Lo hace con undeterminado '''''cargo'''''.
| + | |
| − | [[Imagen:atributo_relacion.png]]
| + | |
| − | {{Nota;: Los atributos pueden ser también de la relación}}
| + | |
| − | }}
| + | |
| − | }}
| + | |
| − | | + | |
| − | =====Interrelaciones o vínculos=====
| + | |
| − | <br />
| + | |
| − | {{MRM_Definicion|Title=Relaciones|
| + | |
| − | *Establecen las cardinalidades entre los elementos que se relacionan de entidades
| + | |
| − | [[Imagen:cardinalidades_1.png]]
| + | |
| − | *Sólo nos interesan los valores mínimos ( 0 o 1) y los máximos ( 1 o n).
| + | |
| − | *Lo que hay que hacer es establecer las preguntas de formas correctas.
| + | |
| − | {{MRM_Ejemplos|Title=Analicemos el caso anterior|
| + | |
| − | {{MRM_Pregunta|Title=Pregunta para obtener el mínimo ( 0 o 1)|
| + | |
| − | ;Puede un cliente no tener facturas
| + | |
| − | Si es '''''SI''''' entences ponemos un '''''0'''''
| + | |
| − | Si es '''''NO''''' entences ponemos un '''''1'''''
| + | |
| − | }}
| + | |
| − | {{MRM_Pregunta|Title=Pregunta para obtener el máximo ( 1 o N)|
| + | |
| − | ;Puede un cliente tener muchas facturas
| + | |
| − | Si es '''''SI''''' entences ponemos un '''''N'''''
| + | |
| − | Si es '''''NO''''' entences ponemos un '''''1'''''
| + | |
| − | }}
| + | |
| − | }}
| + | |
| − | {{MRM_Ejemplo|Title=Representación|
| + | |
| − | [[Imagen:Cardinalidades_2.png]]
| + | |
| − | }}
| + | |
| − | {{MRM_Definicion|Title=Cardinalidades de la relación|
| + | |
| − | ;Cogiendo los máximos de las cardinalidades de las entidades, colocamos los máximos en las relaciones
| + | |
| − | *Esta pareja de números se llama la cardinalidad de la relación
| + | |
| − | *Los valores pueden ser '''''(1:1), (M:N) o (1:N)'''''
| + | |
| − | [[Imagen:Cardinalidades_2.png]]
| + | |
| − | }}
| + | |
| − | | + | |
| − | *Lo anteriormente expuesto corresponden a las cardinalidades de la entidad
| + | |
| − | *En el caso anterior diremos que la cardinalidad de '''''Cliente''''' es '''''(1,1)''''' y la de '''''factura''''' es '''''(0,N)'''''
| + | |
| − | *El hecho de ponerlos en los extremos opuestos favorece la lectura
| + | |
| − | Un cliente tiene '''''0''''' o '''''Muchas''''' facturas
| + | |
| − | Una Factura pertenece a '''''1''''' y solo '''''1''''' Cliente
| + | |
| − | }}
| + | |
| − | | + | |
| − | *Pueden ser débil si relacionan una entidad fuerte con una débil
| + | |
| − | ;Cardinalidad
| + | |
| − | *Qué es
| + | |
| − | #Cardinalidad de la entidad
| + | |
| − | #Cardinalidad de la relación
| + | |
| − | ;Relaciones
| + | |
| − | {{Bases_Datos/Modelo_Logico}}
| + | |
| − | ===Nivel Físico===
| + | |
| − | <!--
| + | |
| − | ====Normalización====
| + | |
| − | Las bases de datos han de estar construidas de una forma '''''normal''''', de manera que evitemos redundancias innecesarias, y sólo las mantengamos cuando las consideremos necesarias y seamos conscientes de que existen.
| + | |
| − | *Si hacemos nuestros diseños usando el modelo de chen, garantizamos hasta la '''''3FN'''''
| + | |
| − | {{MRM_Resumen|Title=Formas Normales|
| + | |
| − | ;1FN
| + | |
| − | :Toda tabla tiene una clave primaria y no puede haber valores '''multivaluados''' en la misma tupla
| + | |
| − | ;2FN
| + | |
| − | :Todo atributo no primo depende de forma completa de la clave y no solo de parte de ella
| + | |
| − | ;3FN
| + | |
| − | :Los atributos no primos no implican a otros atributos no primos
| + | |
| − | ;Forma normal de Boyce y Codd.
| + | |
| − | :Los atributos primos que forman una clave no se implican entre ellos }}
| + | |
| − | {{Tip|Atributos '''''primos''''' son los que forman parte de alguna '''clave candidata'''}}
| + | |
| − | {{Tip|Atributos '''''no primos''''' son los que no forman parte de ninguna '''clave candidata'''}}
| + | |
| − | | + | |
| − | ====Usar BD desde un lenguaje de programación ====
| + | |
| − | Una de las principales características que tiene la programación del '''''back-end''''' o programación al lado del servidor es acceder a bases de datos. Esta parte sí que es intrínseca y propia del lado del servidor.
| + | |
| − | Nosotros accederemos a la base de datos desde nuestro programa. Desde él de manera habitual, realizaremos las siguientes acciones :<br />
| + | |
| − | {{MRM_Actividad|Title=Acciones básicas trabajando con bases de datos|
| + | |
| − | 1. -'''''Conectarnos a la base de datos'''''<br />
| + | |
| − | :Para ello necesitamos un software específico del gestor de bases de datos con el que vayamos a trabajar.
| + | |
| − | 2. -'''''Seleccionar'''''<br />
| + | |
| − | :La base de datos con la que vamos a trabajar.
| + | |
| − | 3. -'''''Trabajar con Bases de datos'''''<br />
| + | |
| − | 3.1 -'''''Actuar'''''<br />
| + | |
| − | :acciones a hacer con la base de datos
| + | |
| − | :son las habituales (consultas, inserciones, modificaciones y/o borrados)
| + | |
| − | 3.2 -'''''Procesar información'''''<br />
| + | |
| − | :En caso de consultas deberemos recorrer el cursor u objeto que nos retorne la consulta
| + | |
| − | :Siempre contendrá el conjunto de filas devueltas (en caso de que haya).
| + | |
| − | 3.3 -'''''Cerrar la base de datos'''''<br />
| + | |
| − | :Es importante no dejar conexiones abiertas de forma innecesaria
| + | |
| − | }}
| + | |
| − | <br/>
| + | |
| − | Para realizar estas acciones disponemos de diversas '''''Funciones/Clases''''' específicas dentro de PHP, Nos referiremos a ellos como '''''extensiones''''' de PHP.
| + | |
| − | {{MRM_Puntos clave|
| + | |
| − | ;Independizar la base de datos y el lenguaje de programación: concepto de driver, conector y extensión (mysql, mysqli, PDO).}}
| + | |
| − | {{MRM_Recursos de la Web|Title=Lectura recomendada|
| + | |
| − | http://php.net/manual/es/mysqli.overview.php
| + | |
| − | http://php.net/manual/es/book.pdo.php
| + | |
| − | http://php.net/manual/es/book.mysqli.php
| + | |
| − | }}
| + | |
| − | | + | |
| − | ====Bases de datos y PHP====
| + | |
| − | '''PHP''' tiene un '''''API''''' especifico para trabajar directamente con mysql '''''mysqli''''', el cual incorpora el driver y conector necesario para trabajar con ella de forma nativa. Que el driver sea nativo implica que está implementado utilizando un '''framework''' de extensiones de php.<br />
| + | |
| − | También vamos a disponer de la extensión PDO, la cual se independiza del gestor concreto de bases datos que vayamos a utilizar.
| + | |
| − | ====Extensiones de php====
| + | |
| − | *Por lo tanto en este tema vamos a ver dos extensiones:
| + | |
| − | #'''''mysqli''''' usar una extensión nativa con su SGBD en concreto mysql que viene con el propio lenguaje
| + | |
| − | #'''''PDO''''' usar una extensión genérica que permite conectarse con cualquier gestor de BD, sin necesidad de cambiar nada de código, salvo los parámetros de la construcción del objeto.
| + | |
| − | </div>
| + | |
| − | | + | |
| − | ===Ciclo en el desarrollo de una base de datos===
| + | |
| − | <br />
| + | |
| − | Hay tres niveles como podemos ver en la imagenive
| + | |
| | {{MRM_Definicion|Title=Niveles en el desarrollo de una base de datos| | | {{MRM_Definicion|Title=Niveles en el desarrollo de una base de datos| |
| | #Nivel conceptual | | #Nivel conceptual |
| Línea 349: |
Línea 42: |
| | #Nivel Físico | | #Nivel Físico |
| | }} | | }} |
| − | {{imagen:ciclo_vida_bd.png}}
| + | [[Archivo:ciclo_vida_bd.png]] |
| − | ===Nivel Conceptual===
| + | |
| − | *Corresponde a obtener las especificaciones del cliente
| + | |
| − | *En este nivel debemos establecer comunicación con el cliente y técnicos.
| + | |
| − | ;Cliente
| + | |
| − | Grupo de personas que saben mucho de su negocio, pero seguramente poco de tecnologías de desarrollo
| + | |
| − | ;Técnico
| + | |
| − | Persona/s que tienen (deben tener) un alto conocimiento de desarrollo técnico, pero seguramente saben poco del negocio que han de automatizar
| + | |
| − | ;Objetivo
| + | |
| − | Qué el grupo técnico tenga un conocimiento detallado del negocio y puedan desarrollar una aplicación que satisfaga
| + | |
| − | las necesidades del cliente
| + | |
| − | [[Imagen:especificacion.png]] | + | |
| − | ===Nivel Lógico===
| + | |
| − | ===Nivel Físico===
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| | | | |
| | | | |
| Línea 420: |
Línea 96: |
| | #'''''PDO''''' usar una extensión genérica que permite conectarse con cualquier gestor de BD, sin necesidad de cambiar nada de código, salvo los parámetros de la construcción del objeto. | | #'''''PDO''''' usar una extensión genérica que permite conectarse con cualquier gestor de BD, sin necesidad de cambiar nada de código, salvo los parámetros de la construcción del objeto. |
| | </div> | | </div> |
| − |
| |
| − | ===Ciclo en el desarrollo de una base de datos===
| |
| − | <br />
| |
| − | Hay tres niveles como podemos ver en la imagen
| |
| − | #Nivel conceptual
| |
| − | #Nivel Lógico
| |
| − | #Nivel Físico
| |
| − | [imagen:ciclo_vida_bd.png]
| |
| − | ===Nivel Conceptual===
| |
| − | *Corresponde a obtener las especificaciones del cliente
| |
| − | *En este nivel debemos establecer comunicación con el cliente y técnicos.
| |
| − | ;Cliente
| |
| − | Grupo de personas que saben mucho de su negocio, pero seguramente poco de tecnologías de desarrollo
| |
| − | ;Técnico
| |
| − | Persona/s que tienen (deben tener) un alto conocimiento de desarrollo técnico, pero seguramente saben poco del negocio que han de automatizar
| |
| − | ;Objetivo
| |
| − | Qué el grupo técnico tenga un conocimiento detallado del negocio y puedan desarrollar una aplicación que satisfaga
| |
| − | las necesidades del cliente
| |
| − | [Imagen:especificacion.png]
| |
| − | ===Nivel Lógico===
| |
| − | ===Nivel Físico===
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | ====Normalización====
| |
| − | Las bases de datos han de estar construidas de una forma '''''normal''''', de manera que evitemos redundancias innecesarias, y sólo las mantengamos cuando las consideremos necesarias y seamos conscientes de que existen.
| |
| − | *Si hacemos nuestros diseños usando el modelo de chen, garantizamos hasta la '''''3FN'''''
| |
| − | {{MRM_Resumen|Title=Formas Normales|
| |
| − | ;1FN
| |
| − | :Toda tabla tiene una clave primaria y no puede haber valores '''multivaluados''' en la misma tupla
| |
| − | ;2FN
| |
| − | :Todo atributo no primo depende de forma completa de la clave y no solo de parte de ella
| |
| − | ;3FN
| |
| − | :Los atributos no primos no implican a otros atributos no primos
| |
| − | ;Forma normal de Boyce y Codd.
| |
| − | :Los atributos primos que forman una clave no se implican entre ellos }}
| |
| − | {{Tip|Atributos '''''primos''''' son los que forman parte de alguna '''clave candidata'''}}
| |
| − | {{Tip|Atributos '''''no primos''''' son los que no forman parte de ninguna '''clave candidata'''}}
| |
| − |
| |
| − | ====Usar BD desde un lenguaje de programación ====
| |
| − | Una de las principales características que tiene la programación del '''''back-end''''' o programación al lado del servidor es acceder a bases de datos. Esta parte sí que es intrínseca y propia del lado del servidor.
| |
| − | Nosotros accederemos a la base de datos desde nuestro programa. Desde él de manera habitual, realizaremos las siguientes acciones :<br />
| |
| − | {{MRM_Actividad|Title=Acciones básicas trabajando con bases de datos|
| |
| − | 1. -'''''Conectarnos a la base de datos'''''<br />
| |
| − | :Para ello necesitamos un software específico del gestor de bases de datos con el que vayamos a trabajar.
| |
| − | 2. -'''''Seleccionar'''''<br />
| |
| − | :La base de datos con la que vamos a trabajar.
| |
| − | 3. -'''''Trabajar con Bases de datos'''''<br />
| |
| − | 3.1 -'''''Actuar'''''<br />
| |
| − | :acciones a hacer con la base de datos
| |
| − | :son las habituales (consultas, inserciones, modificaciones y/o borrados)
| |
| − | 3.2 -'''''Procesar información'''''<br />
| |
| − | :En caso de consultas deberemos recorrer el cursor u objeto que nos retorne la consulta
| |
| − | :Siempre contendrá el conjunto de filas devueltas (en caso de que haya).
| |
| − | 3.3 -'''''Cerrar la base de datos'''''<br />
| |
| − | :Es importante no dejar conexiones abiertas de forma innecesaria
| |
| − | }}
| |
| − | <br/>
| |
| − | Para realizar estas acciones disponemos de diversas '''''Funciones/Clases''''' específicas dentro de PHP, Nos referiremos a ellos como '''''extensiones''''' de PHP.
| |
| − | {{MRM_Puntos clave|
| |
| − | ;Independizar la base de datos y el lenguaje de programación: concepto de driver, conector y extensión (mysql, mysqli, PDO).}}
| |
| − | {{MRM_Recursos de la Web|Title=Lectura recomendada|
| |
| − | http://php.net/manual/es/mysqli.overview.php
| |
| − | http://php.net/manual/es/book.pdo.php
| |
| − | http://php.net/manual/es/book.mysqli.php
| |
| − | }}
| |
| − |
| |
| − | ====Bases de datos y PHP====
| |
| − | '''PHP''' tiene un '''''API''''' especifico para trabajar directamente con mysql '''''mysqli''''', el cual incorpora el driver y conector necesario para trabajar con ella de forma nativa. Que el driver sea nativo implica que está implementado utilizando un '''framework''' de extensiones de php.<br />
| |
| − | También vamos a disponer de la extensión PDO, la cual se independiza del gestor concreto de bases datos que vayamos a utilizar.
| |
| − | ====Extensiones de php====
| |
| − | *Por lo tanto en este tema vamos a ver dos extensiones:
| |
| − | #'''''mysqli''''' usar una extensión nativa con su SGBD en concreto mysql que viene con el propio lenguaje
| |
| − | #'''''PDO''''' usar una extensión genérica que permite conectarse con cualquier gestor de BD, sin necesidad de cambiar nada de código, salvo los parámetros de la construcción del objeto.
| |
| − | -->
| |
| | | | |
| | </div> | | </div> |
| | | | |
| | | | |
| − |
| |
| − | </div>
| |
| | |} | | |} |
