Transcription
1. Introduction: La plupart des développeurs voient une base de données comme dans la façon, une nécessité malheureuse. Ce qu'ils ne réalisent pas, c'est que la conception de la base peut créer ou casser votre produit ou fonctionnalité. Hé, je suis [inaudible]. Je suis un Data Scientist dans une petite startup et un doctorant en informatique à l'UC Berkeley. Sur le campus, j'ai enseigné plus de 5 000 étudiants, et hors campus, j'ai reçu plus de 50 critiques cinq étoiles pour enseigner aux gens comment coder votre Airbnb. À la fin de cette classe, vous saurez comment utiliser la base de données InDesign pour votre prochaine grande idée, ce
soit une application aussi simple qu'une tâche ou aussi complexe que Airbnb. Dans cette classe, je vais vous montrer la bonne façon d'organiser vos données, les piliers de la conception et de
l'utilisation de la base de données, de l'écriture de requêtes de base à la conception d'une base de données entière. Pour les développeurs, vous bénéficierez d'une pratique de conception de base de données. Pour les personnes non techniques, vous comprendrez comment communiquer les exigences aux développeurs. Ce cours est conçu pour les personnes ayant peu ou pas d'expérience. Si vous ne savez pas ce qu'est SQL, si vous n'avez jamais utilisé SQL, ou si vous n'avez récupéré que des données
, cette classe est pour vous. Tout ce dont vous avez besoin est un ordinateur, Internet, et environ une heure de temps. C' est une classe pratique, donc vous allez coder chaque seconde du chemin. Vous travaillerez à travers trois études de cas :
une application météo, une application à faire, et enfin une version minimale d'Airbnb. Dans chaque phase, vous allez concevoir, créer, interroger et enfin optimiser une base de données. Je vais vous montrer des exemples de mauvais design et vous donner des conseils pour un bon design. Je suis heureux de vous donner ces outils de conception de base de données et je vais vous expliquer pourquoi ces outils peuvent fabriquer ou casser votre produit dans la prochaine vidéo.
2. Projet : concevoir une base de données: Votre objectif dans cette classe est de concevoir et d'utiliser une base de données. Une bonne conception de base de données est par excellence pour votre produit, et voici pourquoi. Dans n'importe quelle application, la base de données fournit des données au niveau logique. C' est là que les données sont ensuite traitées, triées, analysées à nouveau. Ce niveau logique fournit ensuite des informations à votre interface utilisateur. En conséquence, la base de données a un impact, vraiment, sur toutes les parties de votre application. mauvais choix de conception ralentiront les développeurs, endommageront l'expérience utilisateur avec des temps de chargement médiocres et encourageront les mauvais choix de conception dans toutes les parties de la base de code. C' est une classe pratique, donc vous allez coder chaque étape du chemin. Vous travaillerez à travers trois études de cas,
une application météo , une application à faire, et enfin une version minimale d'Airbnb. Votre projet de classe est de concevoir, créer, interroger, et enfin, optimiser la base de données pour une étude de cas de votre choix. Vous aurez besoin d'accéder à glitch.com et dbdiagram.io. Vous n'avez pas besoin de vous inscrire pour utiliser non plus. Cependant, je suggère de vous inscrire de toute façon afin que vous puissiez enregistrer votre progression. Maintenant, commençons.
3. Cours d'introduction sur les bases de données: Cette leçon servira de base à différents termes et concepts de base de données. Vous vous demandez probablement, qu'est-ce qu'une requête ? Qu' est-ce qu'une base de données ? Une base de données est une collection organisée de données, une requête est la façon dont nous accédons et gérons cette collecte organisée de données. Enfin, SQL ou langage de
requête structuré est un langage que nous utilisons pour exprimer ces requêtes. En conséquence, vous m'entendrez souvent dire requête SQL car ces requêtes sont la façon dont nous interagissons avec la base de données. Une note rapide sur la façon dont les données sont organisées. Pensez à une feuille de calcul Excel, toutes les données sont organisées en tables, chaque table contient un type d'objet comme utilisateur, chaque utilisateur a un certain nombre d'attributs différents, comme ID et nom, comme vous pouvez le voir, chaque attribut est une colonne. Chaque colonne a également un certain type, donc ID est un entier, le nom est du texte. Nous pouvons remplir cette table avec de nouveaux utilisateurs, comme un, John Doe, et deux Jane Doe, comme vous pouvez le voir, chaque ligne est un nouvel utilisateur. C' est tout pour la terminologie. Maintenant, parlons de quelques conseils différents. Voici trois conseils que j'ai pour vous en particulier : Astuce numéro 1, pour gagner le côté de la prudence, toujours copier le code exact que j'ai. Astuce numéro 2, mettez la vidéo en pause si nécessaire. Je vais expliquer chaque ligne de code que j'écris mais si vous avez besoin de temps pour taper et essayer le code vous-même, n'hésitez pas à faire une pause. Astuce numéro 3, vous apprenez mieux en faisant, je suggère de vous mettre en place pour le succès
en plaçant vos fenêtres Skillshare et Glitch côte à côte comme indiqué ici. C' est tout pour des conseils généraux. Dans la leçon suivante, nous allons créer votre première base de données.
4. Cas SQL « Hello World »: Créons une base de données et écrivons nos toutes premières requêtes SQL. Dans cette leçon, vous apprendrez comment configurer une base de données, puis créer, lire, mettre à jour et supprimer des données. Nous allons utiliser une base de données appelée SQLite. Pourquoi j'utilise l'air pour coder n'est pas super important. Tout ce que vous devez savoir est que SQLite ne doit jamais être utilisé en production. Néanmoins, toutes les bases de données que vous utilisez au travail, Postgres, MongoDB, MySQL supportent les mêmes commandes que nous allons utiliser dans cette classe aujourd'hui. Bienvenue à la leçon 4. Allons de l'avant et parlons de ce que nous allons construire exactement. Voici un diagramme. Ce que vous regardez est un diagramme qui répertorie le nom d'un utilisateur de table. Sur la gauche se trouvent les noms de colonnes. Chacun d'entre eux est une propriété d'un utilisateur, l'ID utilisateur, le nom de l'utilisateur et certaines informations sur
le moment où les informations de l'utilisateur ont été créées ou mises à jour. Sur la droite, vous avez les types de colonne, un int pour entier. Pour l'instant, vous pouvez traiter varchar comme du texte, et un horodatage comme une date et une heure. ID ici dans la première ligne en gras, est ce qu'on appelle la clé primaire. La clé primaire identifie de manière unique chaque ligne de nos données et est un must pour toutes les tables. Ces deux lignes, créées à et mises à jour à, sont souvent incluses et recommandées. Maintenant, naviguons vers glitch.com. Une fois cela fait, vous verrez un écran comme celui-ci. Allez-y et cliquez sur « Nouveau projet » en haut à droite et sélectionnez Hello-page web. Vous devriez alors voir une page Web comme celle-ci. Allez-y et en bas à gauche, cliquez sur « Outils » et « Terminal ». Vous verrez un chargement de page comme celui-ci. Allez-y, puis cliquez sur le terminal pleine page. C' est là que nous allons coder. Allons de l'avant et commençons par démarrer une invite. Dans ce terminal, allez de l'avant et tapez sqlite3.data/lesson4.db. Ce premier morceau de texte est la commande sqlite3. Le premier argument, ou le deuxième morceau de texte, est le nom du fichier que nous transmettons. Dans ce cas, nous allons stocker notre base de données dans un fichier appelé .data/lesson4.db. Allez-y et appuyez sur « Entrée ». Maintenant, vous serez accueilli avec l'invite SQLite. Cette invite nous permettra de coder en SQL. Allons de l'avant et créons notre toute première table. Dans cette invite, allez de l'avant et tapez créer des utilisateurs de table. Cet utilisateur aura une colonne ID avec une clé primaire. Cet utilisateur aura un nom requis. Ici, pas null signifie que le nom ne peut pas être laissé vide. Enfin, nous aurons une colonne pour créé à. C' est l'heure à laquelle l'utilisateur a été ajouté à la base de données. Allez-y et ajoutez une parenthèse fermante, puis un point-virgule. Tapez .tables pour répertorier les tables de cette base de données. Ici, nous pouvons voir qu'il ya maintenant une table appelée utilisateurs, confirmant que nous avons créé avec succès notre table d'utilisateurs. Allez-y et tapez dans les utilisateurs .schema pour décrire la table des utilisateurs. Comme vous pouvez le voir, cette description représente fidèlement ce que nous avons tapé précédemment. Maintenant, allons de l'avant et insérons nos données. Allez-y et tapez, insérez dans, passez le nom de la table, qui est utilisateurs. Ensuite, passez dans la colonne que nous voulons remplir, qui est le nom. Enfin, tapez les valeurs que nous voulons remplir. Dans ce cas, John. Maintenant allez-y et répétez la même chose, mais pour un utilisateur nommé Jane. Maintenant, nous pouvons montrer les données que nous avons insérées dans notre tableau. Allez-y et tapez sélectionnez tout parmi les utilisateurs. Cet astérisque signifie ici sélectionner toutes les colonnes. Cela nous permettra d'afficher toutes les colonnes dans le résultat. Ensuite, utilisateurs est le nom de la table à partir de laquelle nous voulons sélectionner nos données. Allez-y et appuyez sur « Entrée », et vous verrez ici que nous avons à la fois l'ID, le nom, puis un champ créé à que nous n'avons pas renseigné. Maintenant, allons de l'avant et parlons d'un autre type de déclaration select. Tapez sélectionnez tous les utilisateurs dont le nom est Jane. Il s'agit maintenant d'une requête de sélection filtrée. L' instruction where nous permet de spécifier les conditions que nous voulons être vraies pour les utilisateurs que nous sélectionnons. Allons de l'avant et mettons à jour les informations de Jane. Tapez la mise à jour, le nom de l'ensemble est égal à Jane Doe. Nous donnons à Jane un nom de famille, où le nom est égal à Jane actuellement. Allez-y et appuyez sur « Entrée ». Une fois de plus, sélectionnez tous les utilisateurs pour confirmer que les informations de nos utilisateurs ont été mises à jour, et nous pouvons maintenant voir que Jane est maintenant Jane Doe. Enfin, allez-y et supprimez l'utilisateur John. Supprimer des utilisateurs dont le nom est égal à John. Pour confirmer que la suppression a réussi, allez de l'avant et sélectionnez tous les utilisateurs une fois de plus. Nous pouvons maintenant voir que l'utilisateur John est parti. Enfin, allez de l'avant et supprimez la table. Utilisateurs de table de dépôt. Nous pouvons confirmer que cette table a été supprimée en tapant .tables pour répertorier toutes les tables. Comme nous pouvons le voir, il ne reste plus de tables, ce qui conclut la partie codante de cette leçon. Allons de l'avant et sautons maintenant à l'examen. Qu' avons-nous appris dans cette leçon ? La première chose à retenir, est que toutes les tables incluent une clé primaire, et qu'elles incluent souvent deux colonnes supplémentaires appelées créées à et mises à jour à. La prochaine étape est qu'il existe plusieurs requêtes SQL courantes que nous avons explorées :
sélectionnez, insérez, mettez à jour et supprimez. Nous avons également exploré un moyen de filtrer les requêtes sélectionnées à l'aide de la clause where. Revoyons la liste des concepts que nous avons appris cette leçon. Vous avez beaucoup appris ces dernières minutes. Nous avons abordé la clause where, les tables de clé primaire, les colonnes, les requêtes et bien d'autres termes que nous n'avons pas répertoriés ici. C' est ça. Ceci conclut la leçon 4.
5. Étude de cas 1 : application météo: Dans cette leçon, nous allons parcourir notre toute première étude de cas, une application météo. Vous aborderez et utiliserez quelques concepts et termes différents. Au lieu de les définir à l'avance, nous les définirons au fur et à mesure que nous les utilisons. Ne vous inquiétez pas, la prochaine diapositive devrait vous sembler complètement étrangère, c'est juste pour dire que nous allons apprendre beaucoup dans cette leçon. Commençons. Dans chacune de nos études de cas, nous suivrons cinq étapes : exigences, conception, optimisation, diagrammes et enfin code. Allons de l'avant et commençons par la toute première étape ici, les exigences. Quelles sont les exigences pour cette application météo ? Cette application météo va avoir plusieurs entités, ces entités incluent l'utilisateur et un fuseau horaire. Comment ces entités sont-elles liées ? Cela fait partie des exigences pour les relations. Chaque fuseau horaire a potentiellement de nombreux utilisateurs, et chaque utilisateur n'a qu'un seul fuseau horaire. Nous appelons cela une relation un-à-plusieurs ; un utilisateur à plusieurs fuseaux horaires, nous en discuterons plus en une seconde. Allons de l'avant et passons à l'étape 2, conception. Ici, vous pouvez voir que vous avez les deux entités, l'utilisateur et le fuseau horaire, et vous pouvez également voir qu'il y a beaucoup d'utilisateurs pour chaque fuseau horaire, donc c'est pourquoi nous appelons cela plusieurs-à-un ou un-à-plusieurs, selon votre point de vue . Parlons d'un mauvais exemple de mise en œuvre de cette exigence. Ici, nous avons une table pour les utilisateurs, comme avant. Maintenant, ajoutons une autre table pour les fuseaux horaires. Nous allons maintenant insérer une référence au fuseau horaire. Voici l'ID de fuseau horaire, qui fait référence au fuseau horaire de chaque utilisateur. Voilà pourquoi c'est une mauvaise idée parce qu'on peut faire mieux. Passons à l'étape 3, optimisation. Avant de le faire, voici un principe que j'aimerais présenter. Dans les bases de données, votre objectif est d'utiliser moins de tables. Astuce numéro 1 est quand vous devez remplacer un un-à-plusieurs par un type de données différent. Dans cet exemple particulier, nous suggérons d'utiliser une énumération, une énumération que vous pouvez considérer comme juste une liste d'options possibles. Nous voulons remplacer une table un-à-plusieurs par une liste d'options possibles lorsque A, vous avez un nombre limité d'options, et B, chaque option a un identifiant unique. Dans ce cas particulier, nous remarquerons que le fuseau horaire satisfait aux deux conditions. Numéro 1, le fuseau horaire a juste un nom et ce nom identifie de manière unique un fuseau horaire. Deuxièmement, nous constaterons qu'il y a un nombre limité de fuseaux horaires, donc à la place, nous allons remplacer cette table par une énumération ou une liste d'options. Maintenant, l'utilisateur a un fuseau horaire attributaire, où le fuseau horaire est contraint d'être en
PDT, EDT, etc. C' est ce qu'on appelle un graphique de relations d'entité, ou pour abrégé, un ERC. Nous allons concevoir un de ces diagrammes dans une seconde. À l'étape suivante, l'étape 4, nous allons au diagramme. Allez-y et accédez à dbdiagram.io dans votre navigateur. Une fois que vous avez accédé à la page Web, allez-y et cliquez sur « Aller à l'application » en haut à droite. La première chose que je vais faire est d'aller de l'avant et de créer une énumération, donc ici nous allons taper enum Timefuseau avec des crochets bouclés, puis aller de l'avant et taper quelques fuseaux horaires différents de votre choix, dans ce cas, nous allons utiliser PDT, EDT et CDT. Maintenant, nous avons une liste de différentes options pour les fuseaux horaires, allons de l'avant et tapez dans notre tableau. Ici, nous allons taper les utilisateurs de Table, comme avant avec des accolades. Tout comme avant, notre table d'utilisateurs aura un identifiant de type entier qui a une clé primaire. Allez-y et ajoutez une autre colonne pour le nom, c'est-à-dire, de type texte, et enfin, ajoutez le fuseau horaire avec le type de fuseau horaire. Ce sont les différentes valeurs que notre utilisateur possède. Maintenant, allons de l'avant et ajouter deux autres colonnes qui sont nécessaires, created_at timestamp et updated_at aussi avec un horodatage. Je vais aller de l'avant et zoomer un peu ici, et ici vous pouvez voir notre table terminée sur la droite. Ceci complète notre diagramme, allons de l'avant et revenons à nos diapositives. Maintenant, allons de l'avant et code. Pour coder, allez de l'avant et revenez à glitch.com. Sur glitch.com, allez de l'avant et accédez à votre projet existant en cliquant sur « Modifier le projet ». Si vous n'avez pas terminé la dernière leçon, allez-y et cliquez sur « Nouveau projet » et « Hello-page Web » et cela ouvrira un nouveau projet. Une fois que vous êtes sur cette page, allez-y et cliquez sur « Outils », « Terminal », puis « Terminal pleine page ». Cela va alors charger une page comme celle-ci. Nous commencerons par lancer l'invite SQLite, comme la dernière fois. Allez-y et tapez sqlite3.data/lesson5.db. Encore une fois, ce premier morceau de texte, sqlite3, est la commande, le deuxième morceau de texte, .data/lesson5.db, est le fichier dans lequel nous stockerons nos données. Allez et appuyez sur « Entrée ». Maintenant, créez votre table d'utilisateurs, CREATE TABLE utilisateurs, cette table commencera par un identifiant, qui est de type INTEGER et est une clé primaire. Ensuite, allez-y et ajoutez une autre colonne comme avant, qui a un nom, et tout comme avant, exiger qu'elle ne soit pas vide. Ajouter un fuseau horaire, et un petit vous a obtenu, est que SQLite n'a pas réellement de types enum, donc à la place, nous allons juste utiliser du texte, enfin, ajouter les deux dernières colonnes, et created_at. Allez-y et ajoutez une parenthèse fermante et un point-virgule. Cela crée maintenant notre nouvelle table d'utilisateurs. Allez-y et insérez quelques valeurs dans ce tableau d'utilisateurs. Encore une fois, spécifiez les colonnes auxquelles vous souhaitez ajouter des valeurs, nom et fuseau horaire, puis spécifiez les valeurs que vous souhaitez insérer. Ici, nous allons insérer quelques lignes différentes. Nous allons avoir un utilisateur nommé John, un utilisateur nommé Jane, et enfin un utilisateur nommé Jenny. Maintenant, continuons et sélectionnons dans cette table, nous allons écrire SELECT all FROM users, cela nous donne les trois utilisateurs que nous avons insérés avec l'id 1, nommé John, id 2, nommé Jenny, et id 3, nommé Jane. Enfin, examinons quelques requêtes différentes que nous aimerions exécuter. Tout d'abord, nous aimerions sélectionner tous les utilisateurs pour un fuseau horaire donné. Donc ici, je vais écrire SELECT tous les utilisateurs FROM où le fuseau horaire est égal à EDT, et comme nous le verrons, nous verrons les deux utilisateurs qui sont dans ce fuseau horaire. Maintenant, allons de l'avant et comptons combien d'utilisateurs sont dans
ce fuseau horaire, c'est un nouveau type de fonction que nous n'avons pas encore vu appelé un agrégateur. Allez-y et écrivez-le dans SELECT COUNT FROM utilisateurs où le fuseau horaire est égal à EDT, et cela nous donne deux, comme nous l'avons vu plus tôt. Encore une fois, nous avons couvert cinq étapes différentes : exigences, conception, optimisation, diagrammes et enfin code. Nous avons abordé un certain nombre de sujets différents
au cours des dernières minutes : le premier est un ERC ou le diagramme, une relation un-à-plusieurs, un agrégateur ou la fonction de comptage que nous avons utilisée, une énumération, et enfin, le cinq- processus étape lui-même. Félicitations, c'est votre toute première conception de base de données pour une application du monde réel. Si vous avez des idées pour une application météo plus cool et plus fantaisiste, n'hésitez pas à modifier l'ERC que nous avons créé dans cette leçon et à le télécharger dans l'onglet Projets de Skillshare. Dans la leçon suivante, nous allons concevoir une base de données pour une application un peu plus compliquée, une application Todo.
6. Étude de cas 2 : application Todo: Dans cette leçon, nous allons parcourir une deuxième étude de cas, une application ToDo pour les exigences de la première étape. Pour cette application ToDo, nous aurons besoin de deux entités différentes. Le premier est un utilisateur
et le second est une tâche. Les relations entre ces entités, chaque utilisateur a de nombreuses tâches. Chaque tâche n'a également qu'un seul utilisateur. On dirait qu'on a juste une autre relation un-à-plusieurs. Parlons de la conception. Ici, nous avons une tâche et un utilisateur. Nous avons beaucoup de tâches pour chaque utilisateur. Nous voyons qu'il s'agit d'un plusieurs-à-un ou d'un un-à-plusieurs. Voici un mauvais exemple. Nous pouvons commencer par essayer ce dont nous avons parlé la dernière fois, qui est d'utiliser un champ de type enum-like. Maintenant, nous ne pouvons pas utiliser une énumération exactement parce que, a, il y a beaucoup d'e-mails d'utilisateurs différents. Il n'y a pas de liste limitée que nous connaissons à l'avance. Deuxièmement, disons que nous voulons ajouter un nom d'utilisateur, alors nous devrions ajouter ce nom et cette
adresse e-mail pour chaque tâche que cet utilisateur a. Au lieu de cela, voici un bon exemple. Nous allons maintenant diviser une table différente pour les utilisateurs. C' est ce qu'on appelle la normalisation. Ici, nous avons une table d'utilisateurs sur la gauche avec le nom et l'e-mail. Maintenant, nous n'avons qu'à stocker les informations des utilisateurs qu'une seule fois. Cependant, maintenant le lien entre l'utilisateur et ses tâches est rompu. Ici, nous devons ajouter quelque chose appelé une clé étrangère. Sur le côté droit, vous avez l'ID utilisateur, qui fait référence à l'utilisateur pour la tâche. Ensuite, allons de l'avant et optimisons. Astuce numéro 2 pour l'optimisation utilise des indices pour des requêtes plus rapides. Les indices uniques sont l'un des plus simples à ajouter. Dans ce cas, il s'agit de l'adresse e-mail de l'utilisateur. Nous nous attendons à ce que chaque utilisateur ait une adresse e-mail différente et unique. Allons de l'avant et passons au diagramme avant naviguer vers dbdiagram.io sur cette page Web. Si vous avez toujours le diagramme d'origine ouvert, passez la souris sur cette liste déroulante et cliquez sur « Nouveau diagramme ». Commençons par créer nos deux tables. Allez-y et saisissez les utilisateurs de la table. Cette table aura un identifiant de type entier qui est une clé primaire. Il aura également un nom avec le texte de type, puis une adresse e-mail également de type texte qui a une contrainte d'unicité. Enfin, ajoutons deux colonnes supplémentaires. Ensuite, ajoutons une énumération pour l'état de la tâche. Ici, nous aurons une énumération de statut, et il y aura deux statuts possibles. Maintenant, allons de l'avant et ajoutons une autre table. Ici, nous aurons une table appelée tâches. Donnez-lui un identifiant avec type entier de clé primaire, puis la clé étrangère dont nous avons parlé plus tôt. Allez-y et tapez user_id de type entier, et nous allons taper ref deux-points supérieur à users.id. Ici users.id fait référence à la table de l'utilisateur, l'id de la colonne. Nous allons maintenant ajouter un statut et ensuite nous allons ajouter une description du texte de type. Enfin, créé à et mis à jour à, et voici les deux tables que nous venons de créer. Ceci conclut notre schéma. Allons de l'avant et passons au code. Étape 5, commencez par naviguer sur glitch.com. Une fois là, vous devriez voir une page comme celle-ci, comme avant. Vous pouvez modifier le projet existant ou vous pouvez taper une nouvelle page web de projet. Une fois que vous aurez fait ça, vous serez accueilli avec une page comme celle-ci. Nous allons écrire un script qui va créer la base de données et ajouter quelques valeurs différentes pour nous dans la base de données. Commencez par appuyer sur Nouveau fichier en haut à gauche, puis tapez lesson6.sql, déposez les utilisateurs de la table, s'il existe. Maintenant, créez une table pour nos utilisateurs et ajoutez l'identifiant, le nom et l'e-mail, et nous allons ajouter la contrainte supplémentaire que cet e-mail est unique. Allons de l'avant et ajoutons maintenant les deux colonnes que nous connaissons. Allons de l'avant et créons les autres tâches de personnes. Tapez l'id. Nous allons ajouter dans user_id, status TEXT, une description aussi de type TEXT. Enfin, les deux colonnes que nous ajoutons toujours. Maintenant, ajoutons ce qu'on appelle la contrainte de clé étrangère. La contrainte de clé étrangère garantit simplement que chaque fois qu'une tâche a un ID utilisateur, cet ID utilisateur fait référence à un utilisateur réel dans la table utilisateurs. Ajoutez cette clé étrangère, qui se réfère à les appeler user_id, qui est censé référencer les utilisateurs de la table et l'id de la colonne. Allez-y et ajoutez un point-virgule pour terminer votre instruction. Nous allons commencer par
insérer certains utilisateurs, INSERT INTO utilisateurs, et nous allons ajouter deux colonnes, nom et e-mail,
avec des valeurs différentes, John, ajouter un point-virgule, et maintenant nous allons aller de l'avant et copier et coller cette ligne et remplacez ces valeurs par Jane. Maintenant, ajoutons quelques tâches pour John. INSERT INTO tâches les colonnes que nous allons remplir, notre user_id, status et description. Maintenant, nous allons ajouter quelques valeurs différentes. Le premier utilisateur inséré ici, John, aura user_id 1. Le statut de cette tâche doit être TODO, et la description sera Natation. Maintenant, nous allons copier et coller et nous allons ajouter une autre tâche pour John. Allons de l'avant et ajoutons d'autres tâches cette fois pour Jane. C'est ça. Glitch enregistre automatiquement ce fichier pour vous. Allons de l'avant et maintenant naviguons jusqu'au terminal. Accédez à Outils, Terminal et Terminal pleine page. Vous verrez alors une page comme celle-ci. Allez-y et tapez sqllite3.data/lesson6.db, allez et appuyez sur Entrée, et maintenant vous êtes dans l'invite SQL. Allons de l'avant et exécutons le fichier que nous venons de créer, .read lesson6.sql. Nous allons d'abord sélectionner toutes les tâches. SELECT astérisque FROM des tâches. Nous allons également sélectionner tous les utilisateurs. Ça a l'air bien. Nous avons à la fois nos utilisateurs et les deux tâches assignées à chacun. Allons de l'avant et maintenant au lieu de sélectionner tout, nous voulons sélectionner des colonnes spécifiques. Ici, nous allons seulement sélectionner le nom et les colonnes e-mail des utilisateurs. Maintenant, nous ne recevons que le nom et l'e-mail de chaque utilisateur. Nous allons maintenant explorer une nouvelle requête appelée JOIN. Nous allons sélectionner à la fois le nom de l'utilisateur et la description de la tâche. Nous allons à SELECT FROM utilisateurs, nous allons JOIN avec la table des tâches, et nous allons les rejoindre lorsque le users_id est égal à la tâche user_id. Allez-y et appuyez sur Entrée, et ici nous pouvons voir tous les John et Jane, et les deux tâches qui sont assignées à chacun. Maintenant, passons en revue cette leçon. Nous avons visité un certain nombre de sujets différents, y compris la dénormalisation, la jointure, les clés étrangères et la normalisation. Nous avons également couvert les indices et ajouté un index unique à la colonne e-mail. Cela conclut cette leçon. Nous avons maintenant terminé une étude de cas pour l'application ToDo. Dans la leçon suivante, vous commencerez une étude de cas pour ABMB.
7. Étude de cas 3 : AirBnb (design): Dans cette leçon, nous commencerons notre troisième étude de cas, Airbnb. Nous allons à nouveau couvrir les cinq étapes différentes, les exigences, la conception, l'optimisation, et nous n'arriverons pas réellement au diagramme ou au code. Commençons, les exigences. Il y a plusieurs exigences différentes. En particulier, les entités qui nous préoccupent sont l'utilisateur, le foyer et plusieurs relations entre ces entités. Les utilisateurs vont visiter de nombreuses maisons. maisons auront beaucoup de visiteurs et une exigence supplémentaire que nous n'avons pas vu auparavant. Les utilisateurs seront également en mesure de posséder des maisons. En d'autres termes, nous avons que les relations sont à la fois plusieurs-à-plusieurs. Il y a beaucoup d'utilisateurs à chaque maison, et il y a beaucoup de foyers pour chaque utilisateur. Les utilisateurs peuvent également posséder des maisons, ce qui signifie qu'il existe différents types de relations. Vous pouvez être propriétaire ou être visiteur. Parlons maintenant du design. Voici les deux entités ; utilisateur et accueil. Il y a beaucoup d'utilisateurs pour chaque maison, et il y a beaucoup de foyers pour chaque utilisateur. C' est notre relation plusieurs-à-plusieurs. Cependant, comment représentons-nous les propriétaires par rapport aux visiteurs ? Voici un mauvais exemple. C' est notre troisième et dernier mauvais exemple. Peut-être que vous connaissez déjà la solution, auquel
cas, génial. Sinon, ne vous inquiétez pas. C'est difficile. Alors, quel est le mauvais exemple ? Ici, nous avons les propriétaires en rouge, et les visiteurs en noir. Nous devons créer un compte pour la possession, et un autre compte pour la visite. Cependant, Airbnb parvient à éviter cela. Vous pouvez créer un compte pour gérer les propriétés et visiter les propriétés en même temps. Comment c'est ? Maintenant, optimisons. Ce que nous allons maintenant faire à la place, c'est associer propriétaire ou visiteur à la relation entre l'utilisateur, et la maison, au lieu de l'associer à l'utilisateur lui-même. Ici, nous verrons que les lignes rouges désignent les relations de propriété. Les lignes noires représentent la visite. Ici, le premier utilisateur en haut à gauche possède deux maisons, et ils visitent le troisième. Cela nous amène à notre conseil numéro 3, envisager d'ajouter des informations aux tables de relations. Parfois, les informations n'appartiennent à aucune entité. Dans ce cas, la relation de propriétaire ou visiteur n'appartient ni à l'utilisateur ni à la maison. Voici le diagramme. Sur le côté droit, nous avons les utilisateurs, sur le côté gauche, nous avons les maisons, et au milieu, nous avons les relations entre les utilisateurs et les maisons. Nous avons également des références à la fois à la maison, et à l'utilisateur de cette table au milieu. Cette table au milieu, les foyers des utilisateurs, est ce qui nous permet de représenter une relation plusieurs-à-plusieurs. Vous remarquerez également que cette table au milieu a une colonne de rôle. Cette colonne de rôle est ce qui distingue les propriétaires des visiteurs. Allons de l'avant
et passons en revue ce dont nous avons parlé dans cette leçon. Vous avez couvert un certain nombre d'étapes différentes. Nous avons couvert les exigences, la conception et l'optimisation. Dans la leçon suivante, nous allons couvrir le diagramme qui conclut cette leçon. Airbnbs, les trois premières étapes de l'étude de cas.
8. Étude de cas 3 : AirBnb (diagramme): Dans cette leçon, nous allons maintenant discuter de l'étape 4 de l'étude de cas Airbnb ; le diagramme. Ici, nous avons déjà terminé les trois premières étapes : exigences, conception et optimisation. Ici, nous allons couvrir le diagramme, et vous vous demandez peut-être pourquoi la moitié du code est réellement mis en évidence. Eh bien, nous allons faire un peu de code dans cette leçon et finir dans la prochaine. Commençons par le diagramme. Comme avant, accédez à dbdiagram.io. Une fois que vous êtes sur dbdiagram.io, si vous ne l'avez pas déjà fait, vous pouvez sélectionner la liste déroulante et cliquer sur « Nouveau diagramme ». Vous serez ensuite accueilli avec un diagramme vide comme celui-ci. Allons de l'avant et créons les trois tables différentes dont nous aurons besoin. Nous allons ajouter la table des utilisateurs. Tout comme avant, nous aurons l'identifiant de type entier qui est une clé primaire. Comme avant, nous aurons également le champ de nom du texte de type, le champ de courrier électronique de type texte, et les deux champs supplémentaires créated_at timestamp et updated_at timestamp. Maintenant, nous allons créer une énumération pour
les différents types de règles qu'un utilisateur pourrait avoir pour un foyer. Donc, ici, nous allons avoir un rôle enum, et le rôle peut être un propriétaire ou un visiteur. Ensuite, nous allons créer une table pour nos maisons. Allons de l'avant et créons une table, des maisons. L' id va être en entier, c'
est-à-dire une clé primaire. Nous allons avoir une adresse pour cette maison, qui est de type texte, un prix par nuit, c'est-à-dire un entier aussi, et enfin, les deux colonnes nécessaires created_at et updated_at. Pour notre troisième et dernière table, nous devrons maintenant représenter la relation plusieurs-à-plusieurs entre les utilisateurs et les foyers. Ici, nous allons avoir une table des utilisateurs, foyers, un identifiant avec un entier et une clé primaire. Nous allons alors avoir des références à la fois aux maisons et aux utilisateurs. Nous allons avoir un identifiant personnel en tant que type entier et c'est une référence de clé étrangère, tout comme nous avons déjà parlé, et nous allons avoir une référence très similaire à la table utilisateur. Ensuite, ajoutez le rôle de cette relation. Ici, nous aurons soit le rôle de propriétaire, soit le rôle de visiteur. Ensuite, nous ajouterons le début, soit le début de la propriété, soit le début de la visite. Enfin, la fin. Ensuite, ajoutez les deux colonnes nécessaires que nous ajoutons toujours, et updated_at. Ceci conclut notre diagramme. Je vais aller de l'avant et zoomer comme avant pour que vous puissiez voir le diagramme entier. Allez-y et cliquez sur « Auto-arranger » et voilà. Nous avons nos utilisateurs, nos maisons et notre table de relations. Maintenant, allons de l'avant et passons à l'étape suivante. Code.
9. Étude de cas 3 : AirBnb (base de données des codes): Ici, nous allons réellement coder juste le début, nous allons créer la base de données. Allez-y et naviguez sur glitch.com, tout comme avant, vous pouvez éditer un projet existant ou cliquer sur « Nouveau projet » et « Hello-Webpage », vous verrez alors une page qui ressemble à celle-ci, allez et cliquez sur « Nouveau fichier » et lesson8.sql. Dans ce fichier, nous allons aller de l'avant et créer la base de données dont nous avons parlé. Allez-y et, comme avant, déposez les tables dans ce script si elles existent déjà. Ici, nous allons aux utilisateurs de DROP TABLE, nous allons aux foyers DROP TABLE et enfin, nous allons à DROP TABLE users_homes. Notez cette convention de nommage, la table de relations entre les utilisateurs et les foyers doit être juste la concaténation de ces deux noms. Maintenant, continuons et créons la table des utilisateurs. Tout comme avant, nous allons avoir l'identifiant, une clé primaire, nous allons avoir le nom, qui va être un TEXT qui n'est pas vide, nous allons avoir l'email qui est TEXT qui n'est pas vide et qui est unique, et alors nous allons avoir les champs updated_at et created_at. Cependant, cette fois, notre champ created_at va s'auto-remplir, aller de l'avant et ajouter une valeur par défaut, c'
est-à-dire le CURRENT_TIMESTAMP. Appuyez sur « Entrée », point-virgule, et cette syntaxe par défaut
remplira réellement ce champ created_at pour nous chaque fois que nous insérons une ligne, nous verrons cela en action dans la leçon suivante. Allons de l'avant et maintenant créer une table de maisons. Nous allons créer des maisons de table, tout comme avant, cette table va avoir un ID de INTEGER, PRIMARY KEY, il va avoir une adresse qui est de type TEXT qui n'est pas vide, un price_per_night de type entier qui n'est pas non plus vide, et enfin, les deux colonnes updated_at et created_at,
comme avant, allez de l'avant et ajoutez une valeur par défaut à created_at de CURRENT_TIMESTAMP. Enfin, nous allons de l'avant et créons notre troisième table. Ici, nous allons CREATE TABLE users_homes. Comme toute autre table,
cette table va avoir votre type INTEGER pour PRIMARY KEY, il va également avoir des références à la fois à la maison et à l'utilisateur. Maintenant, allez-y et ajoutez le rôle pour cette relation, ajoutez le début et la fin, puis, nos deux colonnes préférées updated_at et created_at, comme avant d'ajouter une valeur par défaut. Ensuite, continuons et insérons quelques données dans ces tables. Nous allons, en particulier, insérer certains utilisateurs avec un nom et une adresse e-mail, je vais ensuite copier et coller les utilisateurs restants de la leçon précédente. Maintenant, allons de l'avant et insérons quelques maisons. Nous allons INSCRIRE une adresse et un price_per_night, ici nous aurons une adresse et un price_per_night. Je vais cliquer sur la flèche en haut à gauche, qui minimisera cette barre de navigation afin que vous puissiez voir plus de mon code à la fois, je vais aussi copier et coller cette ligne juste ici afin que nous
puissions modifier les adresses et les prix beaucoup plus rapide. Enfin, ajoutons un peu de propriété. Ici, nous allons INSERT users_homes, nous allons ajouter le home_id, l'user_id, le rôle, le début et la fin ; nous allons ajouter quelques valeurs. Ici, nous allons ajouter dans la première maison, le premier utilisateur avec relation, PROPRIÉTAIRE, et nous allons ajouter une heure de début arbitraire pour le début de la propriété, ici vous pouvez utiliser le format que vous voulez pour le temps, nous allons utiliser un format qui est à peu près similaire à quelque chose appelé un format ISO, cependant, encore une fois, peu importe le format que vous utilisez. Assurez-vous alors d'ajouter un point-virgule à la fin de la ligne, et allez-y et répétez la même chose, mais cette fois pour Jane. Donc Jane est user_id 2 et elle ne peut pas aussi posséder la première propriété, donc nous allons avoir sa propre propriété différente. Maintenant, continuons à copier et coller ceci une fois de plus. Dans cette leçon, nous supposons que chaque maison n'a qu'un seul propriétaire, cependant, vous pourriez en théorie, avec la base de données que vous avez créée, représenter plusieurs propriétaires par maison. Maintenant, continuons et changeons cette maison à la troisième maison, en utilisant
toujours l'utilisateur Jane, qui a user_id 2. Maintenant, enfin, la dernière chose que nous allons ajouter
à ce script est un certain nombre de visites différentes. Allons de l'avant et copions et collez la même ligne, mais maintenant nous allons changer la relation de PROPRIÉTAIRE à VISITEUR, nous allons également changer l'ID de la maison. Donc maintenant, John est propriétaire de la première propriété, donc nous allons demander à John de visiter la deuxième propriété. Allez-y et changez les dates à quelque chose de raisonnable, ici je vais commencer le 5 octobre et se terminer le 7 octobre. Allons maintenant et dupliquons cela quelques fois. Maintenant, nous aurons, à nouveau, John en visite, cette fois il visitera la propriété 3, et il commencera la visite le 7 octobre et visitera jusqu'au 9 octobre. Enfin, nous allons de l'avant et ajoutons notre troisième et dernier visiteur. Ici, nous allons avoir notre nouveau visiteur, Bob, visiter la troisième propriété juste avant John. D' accord. Cela conclut notre code. Dans la leçon suivante, nous allons réellement exécuter ce code, puis nous ferons un peu plus pour interroger ces données. Cela conclut notre leçon ici. C' était l'étape 4 de l'étude de cas d'Airbnb de schémas et un peu de code. Dans la leçon suivante, nous finirons d'interroger les données.
10. Étude de cas 3 : AirBnb (requêtes de code): Bienvenue à la neuvième et dernière leçon de l'étude de cas Airbnb. Dans cette étude de cas, nous allons terminer le code que nous avons commencé la dernière fois, en particulier, nous allons interroger la base de données et les données que nous avons construites et configurées. Comme avant, nous suivons le processus en cinq étapes que nous avons décrit. En particulier, nous avons couvert les exigences, la conception, l'optimisation, le diagramme et enfin, dans cette étape, nous allons couvrir le code. Allez-y et accédez à glitch.com. Une fois sur cette page, vous serez en mesure de trouver votre projet existant et de cliquer sur « Modifier le projet ». Notez que contrairement à auparavant, vous ne pouvez pas démarrer un nouveau projet, car nous devrons utiliser le code que nous avons écrit la dernière fois. Une fois que vous êtes sur glitch.com, vous verrez une page comme celle-ci, allez-y et appuyez sur « Outils » et « Terminal ». Cela vous mènera ensuite à un onglet comme celui-ci. Allez-y et démarrez maintenant l'invite sqlite3 pour une nouvelle base de données. Ici, nous aurons .data/lesson9.db. Maintenant, allons de l'avant et exécutons le script que nous avons écrit dans la dernière lesson.read lesson8.sql. Aucune nouvelle n'est une bonne nouvelle comme avant. Ici, nous pouvons voir qu'il n'y a pas de sortie cependant, cela signifie
que notre script a fonctionné avec succès. Allons de l'avant et construisons maintenant quelques requêtes différentes dont nous pourrions nous soucier. En particulier, nous parlerons des différentes pages
du site Web Airbnb qui sont assez couramment utilisées. Allons de l'avant et construisons maintenant des requêtes pour la page de recherche. Disons que nous voulons énumérer toutes les maisons de moins de 45$ par nuit, aller de l'avant et taper dans sélectionner tous les logements où le prix par nuit est inférieur à 45. Ici, nous n'avons qu'une seule propriété qui satisfait à ces critères. Disons que nous voulons également paginer les résultats, en d'autres termes, montrer un nombre limité de résultats par page. Ici, nous allons sélectionner tous les logements et nous allons limiter le nombre de résultats à deux, et nous allons commencer après le deuxième résultat parce que c'est peut-être la deuxième page de résultats. Ici, nous pouvons voir l'une des propriétés parce que les deux autres propriétés ont déjà été listées. Enfin, essayons de trier par prix. Allez-y et tapez, sélectionnez tout parmi les maisons et commandez par prix par nuit. Comme vous pouvez le voir, les maisons sont maintenant répertoriées dans l'ordre croissant de prix. Examinons maintenant la page hôte. Nous voulons poser des questions sur un hôte particulier, dans ce cas, nous vous demanderons combien de propriétés a Jane ? Nous allons combiner les sujets que nous avons tirés des leçons précédentes. Nous allons d'abord sélectionner, afin de compter, nous allons utiliser le nombre d'agrégateurs, nous allons sélectionner dans les foyers d'utilisateurs, la table de relations. Nous allons nous joindre à la table des utilisateurs car nous devons filtrer les utilisateurs avec le nom Jane. Comme avant, nous devons spécifier comment les tables des utilisateurs et des foyers d'utilisateurs sont liés. Ici, nous avons l'ID des utilisateurs est égal aux foyers des utilisateurs, ID de l'utilisateur. Enfin, nous voulons seulement sélectionner les utilisateurs avec le nom Jane et peut-être plus important, nous voulons seulement sélectionner les relations de propriétaire de type. Ici, on voit que Jane possède deux maisons, comme on s'y attendait. Maintenant, allons-y et découvrons combien de visiteurs l'une des propriétés avait. Ici, nous allons une fois de plus, sélectionner le nombre, nous allons sélectionner dans la table des utilisateurs et des maisons. On va se joindre à la maison. Encore une fois, nous pouvons spécifier comment ces deux tables sont liées et nous allons filtrer uniquement pour la maison qui nous tient à cœur. Dans ce cas, nous nous soucions de 345 Main Street, et nous nous soucions seulement des visiteurs. Ici, nous avons le rôle est égal à visiteur. Comme vous vous y attendez, il y a deux visiteurs. Voyons maintenant une autre page d'Airbnb. Disons que nous voulons explorer la page d'accueil des visiteurs. Dans ce cas, nous voulons répertorier tous les trajets pour un seul utilisateur. Nous allons donc écrire select et nous allons sélectionner l'adresse qu'ils ont visitée, les dates de début et de fin. Nous allons sélectionner parmi les foyers et nous allons rejoindre sur les
relations d'accueil des utilisateurs ou pour spécifier comment ces tables sont liées par leurs ID et nous devons également nous joindre aux utilisateurs. Contrairement à avant, nous avons besoin d'avoir deux instructions de jointure dans cette requête. Il s'agit de l'ID utilisateur. Enfin, nous devons filtrer par tous les utilisateurs avec le nom John, et nous ne sommes intéressés que par les visites au lieu de la propriété. C' est tout, nous pouvons maintenant voir les adresses que John a visitées et ses voyages. Cela conclut le code. Allons de l'avant et revenons à nos diapositives. Ici, nous allons passer en revue les différents concepts dont nous avons discuté. Nous avons discuté de l'ordre, du groupe par, la limite, du décalage et des jointures compliquées. Nous avons utilisé tous ces éléments pour construire des requêtes et notre étude de cas Airbnb pour chaque page du site Web d'Airbnb. Cela conclut la leçon 9. Maintenant, Airbnb lui-même est beaucoup plus fantaisiste que la conception de base de données que nous avons construite. Si vous avez des idées pour étendre cette conception de base de données, allez-y et remue-méninges. Ajoutez à votre [inaudible], développez dessus et partagez dans les onglets du projet. Félicitations pour avoir terminé cette troisième et dernière étude de cas. Regardez la vidéo suivante pour un résumé de ce que vous avez appris et des prochaines étapes.
11. Les prochaines étapes: Vous avez maintenant construit non pas une, mais trois bases de données. Vous avez vu trois exemples de ce qu'il ne faut pas faire, reçu trois conseils de conception de base et couvert un grand nombre de concepts de conception de bases de données différents. Rappelez-vous, la conception de votre base de données est primordiale pour la santé mentale de votre base de code. Obtenez cela bien, et le reste du développement sera beaucoup plus facile. Maintenant, si vous ne l'avez pas déjà fait, choisissez votre application préférée. Il peut s'agir d'une idée existante, d'une idée révolutionnaire que vous seul connaissez, ou d'une nouvelle fonctionnalité. Créez un graphique de relations d'entité et montrez-nous ce que vous avez en le téléchargeant dans l'onglet Projets et ressources. C' est tout, il y a encore des tas à apprendre. Si vous souhaitez passer au niveau supérieur de vos connaissances en conception de base de données, voici une liste de rubriques pour vous lancer d'autres types de base de données, comment communiquer entre le niveau logique
et la base de données et enfin, d'autres concepts de base de données. Veillez également à rechercher d'autres cours sur mon profil Skillshare, y compris ceux en vision par ordinateur, et d'autres en science des données. Félicitations encore une fois pour être arrivé à la fin du cours et jusqu'à la prochaine fois.