Если вы не сталкивались с понятиями «первичный ключ», «вторичный ключ», «внешний ключ», и «сложный ключ», то вам просто необходимо посмотреть этот видео урок.
Как хорошо, что есть люди, которым не лень внятно и на хорошем примере провести брифинг по основным понятиям, привести хинты и разбор часто возникающих ошибок так, чтобы это было приятно смотреть. Сам привык все узнавать из печатных источников, но данный плейлист в изобилии предоставляет всю необходимую информацию.
Первичный ключ - это столбец в базе данных, где каждая строка имеет уникальное значение. Каждая таблица имеет только один первичный ключ. Значения NULL не допускаются. Уникальный ключ - это столбец или группа столбцов, которые вместе содержат уникальные значения. Таблица может иметь более одного уникального ключа. Например, в списке американских граждан столбец с номерами социального страхования будет первичным ключом, а столбцы имени и фамилии в сочетании с номером телефона - уникальным ключом.
Владимир, доброго времени суток. Спасибо за видео. К сожалению, в видео есть две ошибки, вернее одна ошибки и неточность. Реляционные базы данных называются так не потому, что данные одной таблицы связаны с данными другой, а потому, что таблицы в реляционной БД являются представлением некого математического объекта отношения(Relation). Грубо говоря, отношения это сами таблицы, удовлетворяющие некоторому набору правил. А связи между таблицами лучше отношения не называть, чтобы избежать путаницы. Неточность состоит в том, что внешний ключ это, в первую очередь, ограничение целостности данных за которым следит сама СУБД. И если, например, попытаться удалить студента у которого есть предметы, то СУБД либо не даст этого сделать либо удалит соответствующие записи в таблице Ст_Пред. Кстати есть еще одна возможность, выставить в NULL значения ячейки в зависимой таблице, что в вместе с объявлением сложного первичного ключа в таблице связей приведет к ошибке, но для данного примера выставлять в NULL бессмысленно. Еще небольшое замечание, не стоит называть поля словом ключ, опять таки дабы избежать путаницы, лучше Ин(Идентификатор), и сказать что по этому полю создается ключ первичный (внешний) ключ, всё же ключи это слега отдельные от таблиц структуры. Еще раз огромное спасибо за видео, оно после прочтения нудных теоретических книжек позволяет "оживить" прочитанное.
Вот мне всё-таки интересно узнать. В книге Криса Файли "SQL" написано: "Имейте в виду, что прилагательное «реляционная» (relational), которое входит в название «реляционная база данных» (relational database), появилось благодаря математической «реляционной теории множеств» (relational set theory), а не из-за возможности устанавливать связь (to relate) между разными таблицами по их общим значениям." Так кому верить? Если тут и многие говорят, что "реляционная" от "устанавливать связь"? А в книге наоборот....
Отличный урок, Володя, спасибо! Но мне кажется, я бы не понял это, если бы у меня не было опыта в создании базы данных в Access. Я реализовывал это на практике, но не догадывался, вы же все поставили по полочкам.
Спасибо за видео. Очень хотелось бы увидеть видео, где объясняются базовые понятия реляционных баз данных в вашем представлении. Судя по вашим словам в вашем понимании термин "Отношение" не совпадает с соответствующим термином в теории реляционных БД, где я как я понимаю отношение есть сама таблица с определёнными условиями.
Anatoli Zaharenko вы правы, в РСУБД отношение это набор строк и столбцов. Это может быть как таблица, так и результат выборки из несколькиъ таблиц путем объединения (union), соединения (join), произведения (cross join) и т.д.
Здравствуйте! Большое спасибо за видео, очень доступно и максимально понятно. Подскажите пожалуйста, какой выбрать для изучения язык программирования. В данный момент работаю уже год в QA, хочу развиваться дальше в этой отросли. Спасибо
Володя привет, подскажите - я даже когда использую сложный ключ все равно в таблице делаю автоинерементное поле - как Вы считаете это верно или все же лишняя трата ресурса
+Sasha Gedz Я-бы не стал делать ещё одно поле. Когда программист видит таблицу где 2 внешних ключа формируют 1 сложный ключ, то сразу понимает в чём тут дело (связь много к многому). В том что вы делаете нет ничего плохого (количество затраченых ресурсов минимальное, не стоит волноваться если вы не вставляете что-то в эту таблицу миллионы раз в минуту), просто вы немного откланились от конвенций. Хотя вы можете найти себя работающим в компании где (например) есть правило, что все таблицы обязательно должны содержать только 1 ключевое поле, которое автоинкриментируется. И в такой организации ваш подход как раз будет "правильным" (даже единственно правильным).
Vladimir Mozhenkov Большое спасибо за полный ответ, я как раз отношусь к людям которые долго и упорно что-то делают потом видят другой поход и начинают сомневаться в правильности всего что они делали до этого =), с каждым днем Ваш канал все интереснее и все время есть что-то новое - еще раз спасибо!
добавим год в ДР? а какого типа ДР? если это дата, то там уже есть год. не дата? нарушение 1НФ? непонятно. Но у нас тут про рсубд, кого волнуют какие-то там домены/типы.
Владимир, доброго времени суток! Возможно Вам покажется, что я не прав, но все-же. Мне кажется, что в Ваших видео не хватает академичности. Например, про потенциальный ключ ничего не было сказано, да и определения послушать иногда хочется. В остальном - Вас послушать интересно.
+Виктор Пунин Согласен. Но, скажу вам честно, я просто помню, когда я сидел на уроке по базам данных и нам рассказывали про ключи, очень долго обсуждали потенциальные ключи и как стоит с ними работать, я долго потылся разобраться в этом, и в конце понял, что это что-то, что программист делает на автомате, и даже не задумывается о том, как это называется (и то, что я уже до посещения этого класса делал когда столкнулся с бд). Мне кажется, что сейчас хватает литературы, где объясняют "академически". Возьмём JOIN-ы. Я вижу что многие университеты начинают их объяснение с того, чтобы доказать математически, что данные, которые они выдают "правильны". То есть сидит человек и пытается понять разницу между INNER и OUTER, а ему приводят довод за доводом, что мол информация не теряется. Я подошёл к проблеме с другой стороны. Вот вы программист, у вас есть данные, что с ними сделать. Вот прямо сейчас. Соглашусь с вами, что для общего развития, будет хорошо, если программист попытается понять проблему более углублено. Тогда он/она поймёт почему-же мы делаем так а не иначе. И даже будет ясно почему денормализация - это полезная, но опасная вещь.
11:50 в начале лучше без чтения какой либо документации попробовать сделать самому, а потом посмотреть уроки чтоб понять как сделать было бы лучше. Так и легче воспринимать то что говорит лектор, потому что кое как уже знаешь как оно устроено в самой программе.
Иисус лучший, божественно объясняет
Покайся
Как хорошо, что есть люди, которым не лень внятно и на хорошем примере провести брифинг по основным понятиям, привести хинты и разбор часто возникающих ошибок так, чтобы это было приятно смотреть.
Сам привык все узнавать из печатных источников, но данный плейлист в изобилии предоставляет всю необходимую информацию.
+Fake Potato )) Очень рад, что помогаю ))
Если бы я все узнавала по печатным источникам, то ничего бы не поняла. Спасибо тем, кто придумал Ютуб.
Вы просто лучший, о-о-очень доступно и доходчиво.
Спасибо, ты преподаешь как Боженька. По твоему видео разобрался с джоинами, хотя до этого до конца долго понять не мог. Еще раз спасибо тебе большое.
Очень толковое объяснение ключей! Спасибо )
Большое спасибо, усваивается на 146%, словно с ложечки накормили информацией) Подписка однозначно!
Мне кажется, если Володя так же будет рассказывать про существования Бога, то я смогу понять и поверить в его существования. Володя, супер!
Спасибо большое! Очень интересно и доходчиво!
Спасибо. Всё доходчиво и предельно ясно)
Не у всех есть талант доходчиво объяснять (учить). Спасибо! И разъяснения на доске лучше воспринимаются))
Прикольный канал, прикольный диктор )))) Очень понятно рассказывает, молодец )))) Ждем ещё твоих выпусков ))))
ну как же не поставить лайк за такое простое и доступное объяснение. :-)
большое спасибо вам! все очень доходчиво и понятно
Спасибо очень полезная информация,долго искал,и нашел,Спс еще раз.)
Более менее понял наконец-то.
Спасибо за краткое понятное объяснение.
Отличный у вас и очень информативный канал
Первичный ключ - это столбец в базе данных, где каждая строка имеет уникальное значение. Каждая таблица имеет только один первичный ключ. Значения NULL не допускаются. Уникальный ключ - это столбец или группа столбцов, которые вместе содержат уникальные значения. Таблица может иметь более одного уникального ключа. Например, в списке американских граждан столбец с номерами социального страхования будет первичным ключом, а столбцы имени и фамилии в сочетании с номером телефона - уникальным ключом.
Блин - чувак хочу что бы ты у нас в шараге преподавал....
Очень классно объясняешь - все понятно.... респект тебе :) так держать!
Чувак выделяется запятыми, а не тире)
@@daniilzhmak5084 ты решил что слово шарага в его предложении просто так?
Огромное тебе спасибо!
Игумен интересно излагает!!Спасибо ему !!
спасибо большое. всё предельно ясно
Володя, спасибо!
Отлично. Спасибо!
Спасибо ! Преподаватель от Бога !
Спасибо за видео!!!
Боже мой! Это видео от Бога!
спасибо большое, очень помогли!
Владимир, доброго времени суток.
Спасибо за видео. К сожалению, в видео есть две ошибки, вернее одна ошибки и неточность.
Реляционные базы данных называются так не потому, что данные одной таблицы связаны с данными другой, а потому, что таблицы в реляционной БД являются представлением некого математического объекта отношения(Relation). Грубо говоря, отношения это сами таблицы, удовлетворяющие некоторому набору правил. А связи между таблицами лучше отношения не называть, чтобы избежать путаницы.
Неточность состоит в том, что внешний ключ это, в первую очередь, ограничение целостности данных за которым следит сама СУБД. И если, например, попытаться удалить студента у которого есть предметы, то СУБД либо не даст этого сделать либо удалит соответствующие записи в таблице Ст_Пред. Кстати есть еще одна возможность, выставить в NULL значения ячейки в зависимой таблице, что в вместе с объявлением сложного первичного ключа в таблице связей приведет к ошибке, но для данного примера выставлять в NULL бессмысленно.
Еще небольшое замечание, не стоит называть поля словом ключ, опять таки дабы избежать путаницы, лучше Ин(Идентификатор), и сказать что по этому полю создается ключ первичный (внешний) ключ, всё же ключи это слега отдельные от таблиц структуры.
Еще раз огромное спасибо за видео, оно после прочтения нудных теоретических книжек позволяет "оживить" прочитанное.
Отличное, годное уточнение к сказанному в видео.
Спасибо, все понятно!
Офигенно объяснил!!!
спасибо большое за SQL лекции
Офигенные лекции 👍
Большое спасибо.
желаю всем подобных преподавателей
Спасибо большое)) разобрался))
Спасибо!
Итак, 3 ключа: первичный, сложный и внешний !
Какой колоритный персонаж.. Автор наверное поклонник эпохи 70-х годов американских хиппи😁
Вы такой чистый классный объяснятель :-) а про триггеры и пример вставки с тригером?
Вот мне всё-таки интересно узнать. В книге Криса Файли "SQL" написано: "Имейте в виду, что прилагательное «реляционная» (relational), которое входит в название «реляционная база данных» (relational database), появилось благодаря математической «реляционной теории множеств» (relational set theory), а не из-за
возможности устанавливать связь (to relate) между разными таблицами по их общим значениям."
Так кому верить? Если тут и многие говорят, что "реляционная" от "устанавливать связь"? А в книге наоборот....
Подписался и сразу лайк поставил!)
Отличный урок, Володя, спасибо!
Но мне кажется, я бы не понял это, если бы у меня не было опыта в создании базы данных в Access. Я реализовывал это на практике, но не догадывался, вы же все поставили по полочкам.
Круто!
Спасибо
УУУХ, мало где есть такой стиль преподавания. Спасибо за уроки
Благодарю
Типы ключей в базе данных 2021 )) Спасибо
Спасибо за видео. Очень хотелось бы увидеть видео, где объясняются базовые понятия реляционных баз данных в вашем представлении. Судя по вашим словам в вашем понимании термин "Отношение" не совпадает с соответствующим термином в теории реляционных БД, где я как я понимаю отношение есть сама таблица с определёнными условиями.
Anatoli Zaharenko вы правы, в РСУБД отношение это набор строк и столбцов. Это может быть как таблица, так и результат выборки из несколькиъ таблиц путем объединения (union), соединения (join), произведения (cross join) и т.д.
Гениально.
Владимир, раскажите пожалуйста про внешний ключ.
Я поставил 1000-й лайк! Ура, товарищи)))
Здравствуйте! Большое спасибо за видео, очень доступно и максимально понятно. Подскажите пожалуйста, какой выбрать для изучения язык программирования. В данный момент работаю уже год в QA, хочу развиваться дальше в этой отросли. Спасибо
Иисусе, ты кросавчег! Хоть я и атеист , но такой Иисус даже мне по душе ! Лайк!
все бы так объясняли..
Огонь)
Спасибо!
п.с. 6:07 даешь ро-о-ок! =)
ещё и длинные волосы, то что надо для рока
Дякую!!!
я просто перепил но не был накурен в польезде,Господи спасибо!!!
Володя привет, подскажите - я даже когда использую сложный ключ все равно в таблице делаю автоинерементное поле - как Вы считаете это верно или все же лишняя трата ресурса
+Sasha Gedz Я-бы не стал делать ещё одно поле. Когда программист видит таблицу где 2 внешних ключа формируют 1 сложный ключ, то сразу понимает в чём тут дело (связь много к многому). В том что вы делаете нет ничего плохого (количество затраченых ресурсов минимальное, не стоит волноваться если вы не вставляете что-то в эту таблицу миллионы раз в минуту), просто вы немного откланились от конвенций.
Хотя вы можете найти себя работающим в компании где (например) есть правило, что все таблицы обязательно должны содержать только 1 ключевое поле, которое автоинкриментируется. И в такой организации ваш подход как раз будет "правильным" (даже единственно правильным).
Vladimir Mozhenkov Большое спасибо за полный ответ, я как раз отношусь к людям которые долго и упорно что-то делают потом видят другой поход и начинают сомневаться в правильности всего что они делали до этого =), с каждым днем Ваш канал все интереснее и все время есть что-то новое - еще раз спасибо!
Можно ли что-нибудь узнать об индексации таблиц?
+Ололондий Ололоев ))) видео уже записаны. сейчас скоро буду выкладывать.
Мировой мужик
Блин, Иисус, вот отлично все, но надо показать на практике все таки.
в почти университете должна быть почти кафедра хД
добавим год в ДР? а какого типа ДР? если это дата, то там уже есть год. не дата? нарушение 1НФ? непонятно. Но у нас тут про рсубд, кого волнуют какие-то там домены/типы.
Божья роса подъехала, после нескольких дней боли с горедокладчиков
Владимир, доброго времени суток!
Возможно Вам покажется, что я не прав, но все-же. Мне кажется, что в Ваших видео не хватает академичности. Например, про потенциальный ключ ничего не было сказано, да и определения послушать иногда хочется.
В остальном - Вас послушать интересно.
+Виктор Пунин Согласен. Но, скажу вам честно, я просто помню, когда я сидел на уроке по базам данных и нам рассказывали про ключи, очень долго обсуждали потенциальные ключи и как стоит с ними работать, я долго потылся разобраться в этом, и в конце понял, что это что-то, что программист делает на автомате, и даже не задумывается о том, как это называется (и то, что я уже до посещения этого класса делал когда столкнулся с бд).
Мне кажется, что сейчас хватает литературы, где объясняют "академически".
Возьмём JOIN-ы. Я вижу что многие университеты начинают их объяснение с того, чтобы доказать математически, что данные, которые они выдают "правильны". То есть сидит человек и пытается понять разницу между INNER и OUTER, а ему приводят довод за доводом, что мол информация не теряется.
Я подошёл к проблеме с другой стороны. Вот вы программист, у вас есть данные, что с ними сделать. Вот прямо сейчас.
Соглашусь с вами, что для общего развития, будет хорошо, если программист попытается понять проблему более углублено. Тогда он/она поймёт почему-же мы делаем так а не иначе. И даже будет ясно почему денормализация - это полезная, но опасная вещь.
Ещё все видео были бы связано как-то, а не просто свалены в плейлист..
key=ID
топ
володья, каменный век давно закончился, берешь шистый пальец, компутер, программульку записи видео с монитора, и пишешь человеческое видео
Я уверовал
я тоже...
Ему бы Head&Shoulders рекламировать, а не базам учить=)
Это же Иисус спустился к нам, чтобы помочь понять БД!
Начинаю понемногу верить в Иисуса
11:50 в начале лучше без чтения какой либо документации попробовать сделать самому, а потом посмотреть уроки чтоб понять как сделать было бы лучше. Так и легче воспринимать то что говорит лектор, потому что кое как уже знаешь как оно устроено в самой программе.
Вы верите в бога Иисуса?
тупейшее приветствие продоброе время суток
тупейший комментарий под видео
неприятно смотреть на такого старца
Спасибо!
Спасибо!