Diferencia entre revisiones de «Plantilla:PHP/ConceptosGeneralesBaseDatos»
(→Sistema Gestor de Bases de datos) |
(→Conceptos del nivel lógico: Dominio y atributo) |
||
(61 revisiones intermedias por el mismo usuario no mostrado) | |||
Línea 1: | Línea 1: | ||
<div id=parrafo> | <div id=parrafo> | ||
===BASES DE DATOS: Introducción=== | ===BASES DE DATOS: Introducción=== | ||
− | Una muy breve introducción sobre lo que es una '''''base de datos'''''. Es éste un concepto conocido, pues | + | Una muy breve introducción sobre lo que es una '''''base de datos'''''. Es éste un concepto conocido, pues es un término que habitualmente usamos de forma coloquial.<br /> |
− | + | ||
{{MRM_Definicion|Title=Base de datos| | {{MRM_Definicion|Title=Base de datos| | ||
− | Una base de datos es una colección o conjunto de datos que vamos a almacenar en un dispositivo de almacenamiento permanente ( | + | Una base de datos es una colección o conjunto de datos<br /> |
+ | que vamos a almacenar en un dispositivo de almacenamiento permanente (generalmente HD)<br />, | ||
+ | que tiene una determinada estructura u organización, la cual nos va a permitir operar de una forma organizada y rápida con esos datos}}<br /> | ||
[[Imagen:bibliotecaMRM.jpg|center]]<br /> | [[Imagen:bibliotecaMRM.jpg|center]]<br /> | ||
− | Sería inimaginable buscar un libro en una biblioteca si no hubiera una | + | |
+ | Sería inimaginable buscar un libro en una biblioteca si no hubiera una organización u orden para localizarlo o a la hora de añadir un libro nuevo (en una sección, en una estantería concreta y no en cualquiera.<br /> | ||
[[Imagen:libroGrande.jpg|center]]<br /> | [[Imagen:libroGrande.jpg|center]]<br /> | ||
Igualmente si voy a tener libros pequeños, los pondré en estanterías pequeñas, si voy a almacenar libros grandes necesitaré tener estanterías grandes.<br /> | Igualmente si voy a tener libros pequeños, los pondré en estanterías pequeñas, si voy a almacenar libros grandes necesitaré tener estanterías grandes.<br /> | ||
Siguiendo esta lógica, las bases de datos han de estar preparadas para almacenar el tipo de información que nos pueda venir, para ello habrá que hacer un diseño correcto de las tablas y atributos para poder almacenar toda la información de nuestro sistema.<br /> | Siguiendo esta lógica, las bases de datos han de estar preparadas para almacenar el tipo de información que nos pueda venir, para ello habrá que hacer un diseño correcto de las tablas y atributos para poder almacenar toda la información de nuestro sistema.<br /> | ||
+ | Esto implica tener que realizar un análisis detallado del sistema, buscando de alguna forma todos los posibles casos que se pueden producir para tener la base de datos preparada para que esa situación se pueda almacenar en forma de datos dentro de mi sistema | ||
{{MRM_Puntos clave| | {{MRM_Puntos clave| | ||
El diseño de la base de datos es un factor fundamental para el éxito de la aplicación}} | El diseño de la base de datos es un factor fundamental para el éxito de la aplicación}} | ||
{{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}} | ||
− | ;Normalización | + | ===Sistema de información=== |
− | Las bases de datos han de estar construidas de una forma '''''normal''''', de manera que evitemos redundancias | + | <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=== | ||
+ | <br /> | ||
+ | Hay tres niveles como podemos ver en la imagenive | ||
+ | {{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 | ||
+ | |||
+ | ===Nivel Lógico=== | ||
+ | *A este nivel vamos a usar el '''''modelo relacional''''' | ||
+ | *Es importante tener claro que lo que queremos realizar a este nivel es '''''aplicar una serie de reglas para transformar el modelo entidad/interrelación o modelo de Chen en un modelo relacional''''' | ||
+ | {{MRM_Clave|Title=Paso del modelo E/R a modelo Relacional| | ||
+ | [[Imagen:modelo_er2mr.png]] | ||
+ | }} | ||
+ | *En este nivel hay que estudiar una serie de conceptos sencillos, que convienen dejar claros | ||
+ | {{MRM_Actividad|Title=Elementos del nivel lógico| | ||
+ | ;Dominio y atributo | ||
+ | ;Relación y tupla | ||
+ | ;Restricciones | ||
+ | }} | ||
+ | |||
+ | ====Conceptos del nivel lógico: Dominio y atributo==== | ||
+ | <br /> | ||
+ | {{MRM_Definicion|Title=Dominio| | ||
+ | Un dominio es el conjuntos de valores | ||
+ | que puede tomar un determinado atributo (campo) | ||
+ | de un elemento concreto (tupla o fila) del objeto (relación o tabla). | ||
+ | [[Imagen:dominio.png]] | ||
+ | }} | ||
+ | |||
+ | ====Conceptos del nivel lógico: Dominio y atributo==== | ||
+ | ====Conceptos del nivel lógico: Dominio y atributo==== | ||
+ | ===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''''' | *Si hacemos nuestros diseños usando el modelo de chen, garantizamos hasta la '''''3FN''''' | ||
{{MRM_Resumen|Title=Formas Normales| | {{MRM_Resumen|Title=Formas Normales| | ||
;1FN | ;1FN | ||
− | :Toda tabla tiene una clave primaria y no puede haber valores multivaluados en la misma tupla | + | :Toda tabla tiene una clave primaria y no puede haber valores '''multivaluados''' en la misma tupla |
;2FN | ;2FN | ||
:Todo atributo no primo depende de forma completa de la clave y no solo de parte de ella | :Todo atributo no primo depende de forma completa de la clave y no solo de parte de ella | ||
Línea 27: | Línea 313: | ||
:Los atributos primos que forman una clave no se implican entre ellos }} | :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 '''''primos''''' son los que forman parte de alguna '''clave candidata'''}} | ||
− | {{Tip|Atributos no primos son los que no forman parte de ninguna clave candidata}} | + | {{Tip|Atributos '''''no primos''''' son los que no forman parte de ninguna '''clave candidata'''}} |
− | === | + | ====Usar BD desde un lenguaje de programación ==== |
− | <br /> | + | 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| | ||
+ | #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/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> | ||
− | + | ===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=== | ||
− | < | + | |
− | ;Extensiones de php | + | |
+ | |||
+ | |||
+ | |||
+ | ====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: | *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 | #'''''mysqli''''' usar una extensión nativa con su SGBD en concreto mysql que viene con el propio lenguaje | ||
− | #'''''PDO''''' usar una extensión | + | #'''''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> |
Última revisión de 00:51 25 abr 2018
Contenido
BASES DE DATOS: Introducción
Una muy breve introducción sobre lo que es una base de datos. Es éste un concepto conocido, pues es un término que habitualmente usamos de forma coloquial.
Una base de datos es una colección o conjunto de datos |
Sería inimaginable buscar un libro en una biblioteca si no hubiera una organización u orden para localizarlo o a la hora de añadir un libro nuevo (en una sección, en una estantería concreta y no en cualquiera.
Igualmente si voy a tener libros pequeños, los pondré en estanterías pequeñas, si voy a almacenar libros grandes necesitaré tener estanterías grandes.
Siguiendo esta lógica, las bases de datos han de estar preparadas para almacenar el tipo de información que nos pueda venir, para ello habrá que hacer un diseño correcto de las tablas y atributos para poder almacenar toda la información de nuestro sistema.
Esto implica tener que realizar un análisis detallado del sistema, buscando de alguna forma todos los posibles casos que se pueden producir para tener la base de datos preparada para que esa situación se pueda almacenar en forma de datos dentro de mi sistema
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
Es la parte lógica o de información de un determinado sistema. |
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
Hay tres niveles como podemos ver en la imagenive
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 |
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
Modelado conceptual
- 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}}
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. |
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
El conjunto de elementos u objetos concretos o abstractos de los que se quiere almacenar información dentro de este sistema |
- Representación gráfica
- Su representación es un rectángulo
- El nombre se especifica dentro del rectángulo
- Se suelen poner en singular
- Una entidad va a representar un conjunto de elementos, por ejemplo la entidad Alumno representará varios alumnas
- Tipos de entidades
|
{{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
Debilidad en existencia
| |
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
|
- Debilidad en identificación
- Son entidades que dependen de otra para que existan o incluso para poderse identificar
- Se representan con un doble cuadrado
Debilidad en identificación
| |
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.
|
- 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
|
- Concepto de agregación
Atributos
- Qué son
|
- Tipos de atributos
|
|
{{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.
Representación
| |
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
|
- Atributos de la relación
|
Interrelaciones o vínculos
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
Nivel Lógico
- A este nivel vamos a usar el modelo relacional
- Es importante tener claro que lo que queremos realizar a este nivel es aplicar una serie de reglas para transformar el modelo entidad/interrelación o modelo de Chen en un modelo relacional
|
- En este nivel hay que estudiar una serie de conceptos sencillos, que convienen dejar claros
Conceptos del nivel lógico: Dominio y atributo
Un dominio es el conjuntos de valores que puede tomar un determinado atributo (campo) de un elemento concreto (tupla o fila) del objeto (relación o tabla). |