Step 2 (S-44792)

From Stepik Wiki
Jump to: navigation, search

Step on Stepik: https://stepik.org/lesson/14829/step/2

Step 2 (S-44792) 1.png

[00:00 - 00:16] так а на предыдущих уроках мы разобрались а каким образом с помощью джанги обрабатывать и запроса как их можешь сдавать и как генерировать а ответы в том числе с помощью шаблонизатора


[00:16 - 00:33] а важны важной составляющей современных веб приложений является а хранение обработка данных фактически большинство большая часть логики она связана не с кем то вычислениями а с изменением


[00:33 - 00:49] и хранением поиском а в разных приложениях данные могут храниться в совершенно разных структурах это зависит от масштаба мы сами рассматриваем приложение средне


[00:49 - 01:08] рассчитанная на сотни тысяч либо 1000000 человек а в таких приложениях а данные зачастую хранятся в реляционных базах данных теория реляционных баз данных она общем то с ума вполне самостоятельных хорошо развита и


[01:08 - 01:27] по ней существуют отдельные курсы а мы очень кратко посмотрим на возможности которые предоставляет сами базы данных и а в основном будем заниматься а вопросам взаимодействия с базами данных из языка python и своим ворка джанго


[01:27 - 01:43] итак какие задачи вообще решает база данных то есть для хранения можно использовать разные способы в том числе и файл базы данных предоставляет а большое количество разных функционал решает следующие проблемы


Step 2 (S-44792) 2.png

[01:43 - 02:00] 1 это структура хранения как то а не просто звучит но данные нужно хранить в каком то виде рационы баз данных определяет структуру в виде чего хранятся данные о в частности э таблица


[02:00 - 02:19] а база обеспечивает эффективный поиск по данным а что это значит то есть помимо непосредственно хранения данных сложно поддерживать вспомогательные таблицы а вспомогательные структуры данных называемый индекс который обеспечивает быстрый поиск


[02:19 - 02:38] по большому объему данных а зачастую объем данных превышает оперативную память объем оперативной памяти а поэтому всегда есть проблема того что поместить в оперативной памяти а того что оставить на диске то есть база решает задачи по управлению память


[02:38 - 02:55] обеспечивает совместный доступ к данным и как следствие и совместного доступа а при совместном доступе необходимо обеспечивать а независимость атомарность а


[02:55 - 03:14] отдельных пользователей до этого в базах реализован на специальный механизм называемый транзакциями и в конце концов сервера базы данных предоставляет специальные язык для управления а схемой и самими данными займа язык и сквер


[03:14 - 03:30] а мы говорили что данные хранятся в виде таблиц здесь есть важная особенность а


Step 2 (S-44792) 3.png

[03:30 - 03:48] таблица предполагается фиксированное количество столбцов и что важнее тип данных в 1 столбце всегда одинаковый это как бы а 1 из основных положений реляционная алгебра алгебра таблице еще называют соотношениями relation


[03:48 - 04:05] слово делаешь а ну это вопрос rinaldi таблица называется отношение 1 колонка называется атрибутом а 1 строка таблицы заяц кортежем


[04:05 - 04:22] а мы будем использовать такое повседневную технологию таблице строки и колонки а в колонках сосна а могут храниться данные


[04:22 - 04:39] различных типов в 1 колонке всегда только 1 тип а и + в базах данных есть такая вещь как а внешние ключи foreign key что это такое а смотрите


[04:39 - 04:57] записи в разных таблицах могут ссылаться на данные в других таблицах а то есть грубо говоря 1 таблица используется как справа от на данном слайде у нас данном слайде нас проведено


[04:57 - 05:17] 2 таблице в левой таблице блокпост содержатся записи некоторые посты в блоге а в правой таблице а категорий этих постов то есть правой таблицы используются как некоторые справочник соответственно в каждой а в каждом


[05:17 - 05:32] в каждой записи из таблицы постов есть специальный идентификатор идентификатор категории мы видим что таким образом а это то вентилятор совпадает с вентилятором в таблице


[05:32 - 05:51] категории таким образом нас образуется связь между постами и категориями а эта связь позволяет вам не дублировать данные то есть в принципе можно было бы с каждым постом а хранить список его категории а


[05:51 - 06:07] но это к избыточной способ хранения если мы разделяем на 2 таблицы избыточность исчезает а внешние ключи это специальные ограничения в базе данных которые не позволяют вам а занести не соответствующие данным


[06:07 - 06:24] допустим у нас есть всего 4 категория если построен внешний ключ между грязи и идентификаторов категории кто нас не получится например в детстве


[06:24 - 06:41] а разместить число 5 это будет сочтено ошибка а вот так представляется так выглядит моделирования базы данных на на пальце а тем не менее


[06:41 - 06:58] базы сами сервера базы данных язык sql не навязывает каких либо решений по а моделирование в самих данных то есть вполне вполне была возможность разместить все данные в 1 таблице то есть у каждого


[06:58 - 07:14] поста указывать категорию а по каким правилам нужно разделять данные вашего приложения то есть так называемый модель данных по разным таблицам по разным отношением


[07:14 - 07:31] а существует формальная теория заключающаяся в наборе нормально нормально вот звонил в нормальной форме эти нормальные формы выполняются для


Step 2 (S-44792) 4.png

[07:31 - 07:49] база данных либо нет то есть это набор набор правил которые определены математические вы можете просто имея некоторую схему схема базы данных вы можете сказать что эта схема базы данных удовлетворяет там 1 2 и 3 нормальной форме


[07:49 - 08:08] а вот это 1 2 3 4 5 а проблема в том что на практике а на практике сами формы проверка того удовлетворяет базы данных не вытворяет настолько сложны что


[08:08 - 08:24] а на практике программиста этим не занимаются а это можно было бы автоматизировать ну это все равно скорее теоретический подход на практике а этот подход подход сводится к некоторому набору а таких


[08:24 - 08:42] best practice можно сказать а практических правил а в чем они заключаются при проектировании желательно а разбить модель данных соответствия сущности меня реального мира то есть а


Step 2 (S-44792) 5.png

[08:42 - 09:02] просто когда пытаются объяснить описать какую то структуру данных сначала просто попытайтесь представить из каких объектов реального мира она состоит а в случае с блогами постами это немножко не очевидно поскольку и блоге пасты существует только скажем в памяти компьютера


[09:02 - 09:17] а если вы проектируете например базу база данных гибдд с автомобилями а понятно что существуют а автомобили собственно существуют владельцы автомобилей могут быть номера


[09:17 - 09:35] а если немножко поразмыслить это зависит от именно от предметной от предметной области мы можем понять какие соотношения верны и для вот этих объектов например мы можем сказать что 1 автомобиля может быть несколько владельцев а не только 1


[09:35 - 09:52] и номер собственно говоря автомобиля может меняться это может нам дать некоторые некоторые правильные подходы в общем и целом чем а на более мелкие части делится


[09:52 - 10:10] база данных тем меньше избыточность данных там будет а выделение это правило номер 1 личностное разделение сущностей правило номер 2 отделения синтетических первичных ключей


[10:10 - 10:26] а что такое первичный ключ в базе данных первичный ключ это некоторое число либо строка которая уникально идентифицирует а запись то есть рассрочку внутри таблицы


[10:26 - 10:41] внутри 1 таблицы не может быть 2 строк с одинаковыми первичными ключами а что является первичным ключом для автомобиля


[10:41 - 10:58] а можно считать что для автомобиля первичным ключом является его ну то есть это наверно знак который выдан при регистрации можно считать что для автомобиля является номер его кузова которые ставятся


[10:58 - 11:13] а ставится при изготовлении а на практике рекомендуется вводить синтетические первичные ключи что на синтетической знать что не связанные с объектами а практическая область


[11:13 - 11:32] а почему так происходит потому что все другие идентификаторы не имеет тенденцию к изменению то есть и номер кузова может быть сменен при некоторых обстоятельствах и автомобильные номера меняются а лучше вести синтетические кадр который не будет привязан к реальному миру и


[11:32 - 11:51] указывать связей между разными объектами именно через эти синтетические идентификации в базе данных в принципе может быть более 1 ключа то есть ничто не мешает вам сделать синтетические какой то первичной ключ и вместе с тем добавить уникальной уникальны и скажем номер кузова


[11:51 - 12:06] а да я с у нас есть связи между сущностями однако многие многие к 1 например страховка кто кто из водителей месяц


[12:06 - 12:25] право управлять машиной связь многие если не совсем правильно многие ко многим список список владельцев машина есть несколько владельцев выше и актуальный а вот такой вот такую связь нужно делать через внешний ключ


[12:25 - 12:42] то есть а ну что такое внешний ключ мы видим на предыдущем если у нас есть связь многие ко многим а пример связь многие ко многим хорошая только со страховкой каждого автомобиля есть в данный момент времени список людей


[12:42 - 12:58] которыми а которых которые могут им управлять но мы не рассматриваем там без ограничения страховку соответственно каждый человек может управлять там каким то определенным набором автомобилей страховку которых его вписали


[12:58 - 13:13] а такие связи а должны отделался через промежуточную таблицу то есть делается таблицу с автомобилями делается таблице с людьми с водителями и специальные промежуточная таблица которая их связывает


[13:13 - 13:32] а ну такое решение а часто в данных в таблице возникают некоторые поля которое имеется в фиксированное количество значений


[13:32 - 13:50] ну в примере с автомобилем это может быть а тип кузова седан хэтчбек и тому подобное а здесь существует несколько разных решений классическая теория заключается в том что нужно завести отдельную таблицу в которой есть список


[13:50 - 14:09] а типов кузовов и а вместо того чтобы указывать у каждой конкретной машины тип кузова указывается ссылка на запись а в таблице типов то есть foreign key на таблицу тип а


[14:09 - 14:27] при практической разработки чая часто этим пренебрегают и небольшие такие небольшие списке например список типов кузова хранится непосредственно в приложении то есть не видит базу да нет не в базе данных в виде таблицы


[14:27 - 14:44] само приложение в виде какого то перечисление а базе данных хранится поле с типом кино в разных субд по разному называются но тем не менее вводится ограничение и так вот список


[14:44 - 14:59] таких хороших практик проектирования которые позволяют избежать неоднозначностей а позже мы посмотрим как реализован доступ к данным фреймворк django мы увидим что


[14:59 - 15:08] вот эти правила не поощряются то есть они являются естественными для фреймворка junk там просто а сложно спроектировать данные по другому