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