Если вы не сталкивались с понятиями «первичный ключ», «вторичный ключ», «внешний ключ», и «сложный ключ», то вам просто необходимо посмотреть этот видео урок.
Как хорошо, что есть люди, которым не лень внятно и на хорошем примере провести брифинг по основным понятиям, привести хинты и разбор часто возникающих ошибок так, чтобы это было приятно смотреть. Сам привык все узнавать из печатных источников, но данный плейлист в изобилии предоставляет всю необходимую информацию.
Первичный ключ - это столбец в базе данных, где каждая строка имеет уникальное значение. Каждая таблица имеет только один первичный ключ. Значения 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 Большое спасибо за полный ответ, я как раз отношусь к людям которые долго и упорно что-то делают потом видят другой поход и начинают сомневаться в правильности всего что они делали до этого =), с каждым днем Ваш канал все интереснее и все время есть что-то новое - еще раз спасибо!
Владимир, доброго времени суток! Возможно Вам покажется, что я не прав, но все-же. Мне кажется, что в Ваших видео не хватает академичности. Например, про потенциальный ключ ничего не было сказано, да и определения послушать иногда хочется. В остальном - Вас послушать интересно.
+Виктор Пунин Согласен. Но, скажу вам честно, я просто помню, когда я сидел на уроке по базам данных и нам рассказывали про ключи, очень долго обсуждали потенциальные ключи и как стоит с ними работать, я долго потылся разобраться в этом, и в конце понял, что это что-то, что программист делает на автомате, и даже не задумывается о том, как это называется (и то, что я уже до посещения этого класса делал когда столкнулся с бд). Мне кажется, что сейчас хватает литературы, где объясняют "академически". Возьмём JOIN-ы. Я вижу что многие университеты начинают их объяснение с того, чтобы доказать математически, что данные, которые они выдают "правильны". То есть сидит человек и пытается понять разницу между INNER и OUTER, а ему приводят довод за доводом, что мол информация не теряется. Я подошёл к проблеме с другой стороны. Вот вы программист, у вас есть данные, что с ними сделать. Вот прямо сейчас. Соглашусь с вами, что для общего развития, будет хорошо, если программист попытается понять проблему более углублено. Тогда он/она поймёт почему-же мы делаем так а не иначе. И даже будет ясно почему денормализация - это полезная, но опасная вещь.
добавим год в ДР? а какого типа ДР? если это дата, то там уже есть год. не дата? нарушение 1НФ? непонятно. Но у нас тут про рсубд, кого волнуют какие-то там домены/типы.
11:50 в начале лучше без чтения какой либо документации попробовать сделать самому, а потом посмотреть уроки чтоб понять как сделать было бы лучше. Так и легче воспринимать то что говорит лектор, потому что кое как уже знаешь как оно устроено в самой программе.
