En previsión do inicio do próximo caudal ao ritmo Preparamos un pequeno material de autor con consellos importantes para deseñar unha base de datos. Agardamos que este material vos sexa útil.
As bases de datos están en todas partes: desde os blogs e directorios máis sinxelos ata sistemas de información fiables e grandes redes sociais. Se a base de datos é simple ou complexa non é tan importante como é importante deseñala correctamente. Cando unha base de datos está deseñada sen pensar e sen unha comprensión clara do propósito, non só é ineficaz, senón que o traballo posterior coa base de datos será un verdadeiro tormento, un bosque impenetrable para os usuarios. Aquí tes algúns consellos de deseño de bases de datos que che axudarán a crear un produto útil e fácil de usar.
1. Determina para que serve a táboa e cal é a súa estrutura
Hoxe en día, métodos de desenvolvemento como Scrum ou RAD (Desenvolvemento Rápido de Aplicacións) axudan aos equipos de TI a desenvolver bases de datos rapidamente. Porén, na procura do tempo, a tentación é moi grande de mergullarse directamente na construción dunha base, imaxinando vagamente cal é o propio obxectivo, cales deberían ser os resultados finais.
É coma se o equipo se centrase nun traballo eficiente e rápido, pero isto é un espellismo. Canto máis e máis rápido se mergulle na profundidade do proxecto, máis tempo tardará en identificar e modificar os erros no deseño da base de datos.
Polo tanto, o primeiro que debes decidir é definir o propósito da túa base de datos. Para que tipo de aplicación se está a desenvolver a base de datos? O usuario só traballará con rexistros e terá que prestar atención ás transaccións, ou está máis interesado na análise de datos? Onde debería implantarse a base? Seguirá o comportamento dos clientes ou simplemente xestionará as relacións cos clientes?
Canto antes responda o equipo de deseño a estas preguntas, máis suave será o proceso de deseño da base de datos.
2. Que datos debo escoller para almacenar?
Planificar con antelación. Pensamentos sobre o que fará no futuro o sitio ou o sistema para o que se está deseñando a base de datos. É importante ir máis aló dos simples requisitos das especificacións técnicas. Só por favor, non comeces a pensar en todos os posibles tipos de datos que un usuario pode almacenar. En cambio, pensa se os usuarios poderán escribir publicacións, cargar documentos ou fotos ou intercambiar mensaxes. Se este é o caso, cómpre asignarlles espazo na base de datos.
Traballa co equipo, departamento ou organización para o que se apoiará a base de deseño no futuro. Comuníquese con persoas de diferentes niveis, desde especialistas en atención ao cliente ata xefes de departamento. Deste xeito, coa axuda dos comentarios, terás unha idea clara dos requisitos da empresa.
Inevitablemente, as necesidades dos usuarios mesmo dentro do mesmo departamento entrarán en conflito. Se atopas isto, non teñas medo de confiar na túa propia experiencia e atopar un compromiso que se adapte a todas as partes e satisfaga o obxectivo final da base de datos. Tranquilo: no futuro recibirás +100500 en karma e unha montaña de galletas.
3. Modela os datos con coidado
Hai varios puntos clave aos que prestar atención ao modelar datos. Como dixemos anteriormente, a finalidade da base de datos determina que métodos utilizar na modelización. Se estamos deseñando unha base de datos para o procesamento de rexistros en liña (OLTP), é dicir, para crear, editar e eliminar rexistros, utilizamos o modelado de transaccións. Se a base de datos debe ser relacional, o mellor é utilizar o modelado multidimensional.
Durante o modelado, constrúense modelos de datos conceptuais (CDM), físicos (PDM) e lóxicos (LDM).
Os modelos conceptuais describen as entidades e os tipos de datos que inclúen, así como as relacións entre elas. Divide os teus datos en anacos lóxicos: fai a vida moito máis fácil.
O principal é a moderación, non esaxere.
Se unha entidade é moi difícil de clasificar nunha palabra ou frase, entón é hora de usar subtipos (entidades fillas).
Se unha entidade leva a súa propia vida, ten atributos que describen o seu comportamento e a súa aparencia, así como relacións con outros obxectos, entón podes usar con seguridade non só un subtipo, senón tamén un supertipo (entidade pai).
Se ignoras esta regra, outros desenvolvedores confundiranse no teu modelo e non entenderán completamente os datos e as regras de como recollelos.
Os modelos conceptuais impléntanse utilizando os lóxicos. Estes modelos son como unha folla de ruta para o deseño de bases de datos físicas. No modelo lóxico, identifícanse as entidades de datos empresariais, determínanse os tipos de datos e determínase o estado da clave de regra que regula as relacións entre os datos.
Despois compárase o Modelo de datos lóxicos coa plataforma DBMS (sistema de xestión de bases de datos) preseleccionada e obtense un Modelo físico. Describe como se almacenan fisicamente os datos.
4. Use os tipos de datos correctos
Usar un tipo de datos incorrecto pode producir datos menos precisos, dificultades para unir táboas, dificultades para sincronizar atributos e tamaños de ficheiros inchados.
Para garantir a integridade da información, un atributo debe conter só tipos de datos que sexan aceptables para el. Se a idade se introduce na base de datos, asegúrese de que a columna almacene números enteiros dun máximo de 3 díxitos.
Crea un mínimo de columnas baleiras cun valor NULL. Se creas todas as columnas como NULL, este é un gran erro. Se necesitas unha columna baleira para realizar unha función comercial específica, cando os datos son descoñecidos ou aínda non teñen sentido, non dubides en crealos. Despois de todo, non podemos cubrir as columnas "Data de morte" ou "Data de despedimento" con antelación; non somos predictores apuntando co dedo ao ceo :-).
A maioría do software de modelado (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) data permítelle crear prototipos de rexións de datos. Isto garante non só o tipo de datos correcto, a lóxica da aplicación e un bo rendemento, senón tamén que se require o valor.
5. Vaia natural
Ao decidir que columna dunha táboa usar como clave, sempre teña en conta que campos pode editar o usuario. Nunca elixas como clave - unha mala idea. Calquera cousa pode pasar, pero debes asegurarte de que sexa único.
É mellor usar unha clave natural ou empresarial. Ten un significado semántico, polo que evitarás a duplicación na base de datos.
A menos que a clave comercial sexa única (nome, apelidos, cargo) e se repita en diferentes filas da táboa ou deba cambiar, entón a clave artificial xerada debería designarse como clave principal.
6. Normalizar con moderación
Para organizar eficazmente os datos nunha base de datos, cómpre seguir un conxunto de pautas e normalizar a base de datos. Hai cinco formas normais a seguir.
Coa normalización, evita a redundancia e garante a integridade dos datos utilizados na súa aplicación ou sitio.
Como sempre, todo debe ser con moderación, incluso a normalización. Se hai demasiadas táboas na base de datos coas mesmas claves únicas, entón deixouse levar e normalizou en exceso a base de datos. A normalización excesiva afecta negativamente ao rendemento da base de datos.
7. Proba cedo, proba a miúdo
O plan de proba e as probas adecuadas deben formar parte do deseño da base de datos.
A mellor forma de probar a súa base de datos é mediante a integración continua. Simula un escenario de "día na vida dunha base de datos" e comprobe se se xestionan todos os casos extremos e cales son as interaccións probables dos usuarios. Canto antes atopes erros, máis aforrarás tempo e diñeiro.
Estes son só sete consellos que podes usar para deseñar unha gran base de datos de produtividade e eficiencia. Se os segues, evitarás a maioría dos dores de cabeza no futuro. Estes consellos son só a punta do iceberg no modelado de bases de datos. Hai un gran número de trucos de vida. Cales usas?
Fonte: www.habr.com