Привет всем.

Столкнулся с использованием Foreign Key'а , прочитал про него , понял что это внешний ключ который указывает на Primary Key другой таблицы.

У меня есть 2 таблицы :

Employee:
ID INT PRIMARY KEY
Name varchar(255) NOT NULL

EmployeeInProject:
EmployeeID int Foreign Key(Employee.ID)
Phone varchar(50) NOT NULL

Так вот когда я пытаюсь добавить значение в EmployeeID , то у меня выходит ошибка , мол нельзя тут инсёртить.
Ещё мне интересно , Foreign Key равняется значению Primary Key? Т.е он постоянно связан с ним?
Разъясните пожалуйста про этот волшебный ключик.

Заранее благодарен.

gogzor, 
Приветствую.
А где у тебя во второй таблице EmployeeInProject: 
PRIMARY KEY?

В любой таблице должен быть PRIMARY KEY. Он может состоять из одного поля или быть составным, но быть обязан.

А вторичный ключ служит для связи между таблицами.
С твоими таблицами пример приводить не буду, потому как вторая таблица не понятная: что для чего и как.
Приведу свой пример.
Таблица Накладная(содержит данные о шапке документа):
номер накладной - первичный ключ;
дата накладной - поле;
получатель ID -  вторичный ключ.

Таблица товары в накладной(содержит данные о товарах в накладной)
строкаID -  первичный ключ;
номер накладной - вторичный ключ;
товарID - вторичный ключ;
количество -  поле;
цена - поле.

Так вот, в первой таблице номер накладной всегда уникален, так как под одним номером может быть только одна накладная.
А вот во второй таблице номер накладной повторяется, а вот поле строкаID  уникально, т.к. это первичный ключ.
Что это дает, каждая строка имеет свой номер, во втором поле стоит номер накладной к которой относиться эта запись, третье поле указывает (товарID) какую строчку надо посмотреть в таблице товар чтобы получить наименование товара(связь между таблицами). Далее сколько этого товара отпущено и по какой цене.
В следующей накладной может быть тот же самый товар отпущен по другой цене. Т.е. строкаID примет новое значение, номер накладной = номеру следующей накладной в таблице накладная, товарID тотже самый(продаем тотже товар), а вот цена новая(подорожала нефть на рынке, бублики и подорожали).

Понятно?

В данном случае связь один ко многим. Накладная одна, а товаров в ней указано много.
Такая же связь между таблицами накладная-получатель: получатель может быть один, а накладных для него много. Т.е. для нескольких накладных(строки в таблице накладная) в поле получательID стоит номер одного и того же получателя.

Еще эти отношения называют главный - подчиненный. Без главной записи(накладная) нельзя заполнить подчиненнные записи(товар в накладной). Не получиться вставить во вторую таблицу строки содержащие в поле номер накладной(вторичный ключ) номер не сужествующей записи в первой таблице (накладная). 

create table Administrator
(Kod_admina int identity(1,1) primary key,
FIO varchar(20),
Telefon varchar(7),
E_mail varchar(21),
ICQ varchar(9),
Login varchar(10),
PWD varchar(15),
Data_sozdaniya datetime)

create table SMS
(Kod_sms int identity(1,1) primary key,
Ot_kogo_sms varchar(10),
Tekst_sms varchar(125),
Kod_admina int references Administrator(Kod_admina))

Вот примерчик как создавать правильно таблици.

Всё равно както смутно понимается...

Вот мои рабочии таблицы (расписал их в свободном виде) :

Таблица Employee с полями :

ID (Primary Key, int, not null)
Name (varchar(255), not null)
Phone (varchar(50), not null)

Таблица Project с полями :

ID (Primary Key, int, not null)
Name (varchar(255), not null)
ManagerID (Foreign Key, int , not null) <-- Вот это поле указывает на поле ID в таблице Employee

Таблица EmployeeInProject с полями :

ID (Primary Key, int, not null)
EmployeeID (Foreign Key, int, not null) <-- Вот это поле указывает на поле ID в таблице Employee
ProjectID (Foreign Key, int , not null) <-- Вот это поле указывает на поле ID в таблице Project
StartDate (datetime, not null)
EndDate (datetime, not null)

Так вот когда я в чистую таблицу Employee добавил 3 новых значения , им почемуто присвоились ID 7,8,9 .. ПОЧЕМУ?

Я работаю через SQL Server Management Studio сейчас. Может я чтото не то сделал?
Насколько я понял Foreign Key устанавливается в разделе Relationships. Это верно?

P.S Может кто посоветует другие визуальные редакторы SQL Server 2005?


Это сообщение отредактировал(а) gogzor - 17.2.2008, 20:02

gogzor, 
Management Studio  самое то.   


Если поле с автонумерацией и до этого было уже шеть разных записей и все удалены, то это нормально.


Уже на этапе проектирования БД, т.е. создания таблиц нужно понимать как они будут связаны между собой.
А при создании БД в студии, через первичные и вторичные ключи устанавливаются связи между таблицами.
Визуально это делается в "Диаграммы баз данных", там создаешь новую диаграмму, в ней будут отображены твои таблицы с полями и добавляешь там связи между ними.
Так вот в Таблице Employee поле ID это первичный ключ, определяет уникальную запись в этой таблице.
В таблице Project есть поле ManagerID. И как ты правильно написал

Оно указывает что данные проект ведет Employee с указанным ID и его данные можно найти в той таблице по этому ID.

Это делается для того чтобы в таблице проектов не дублировать записи данных о менеджере, а давать "ссылку" на них.

А как сбросить это?

Поле с автоинкрементом значений. По умолчанию начальное значение выставляется в 1, шаг приращения тоже 1. Если бы ты при дизайне таблицы (то что автоматически создась, когда ты выставил inentify в true, и на что ты не обратил внимание) изменил шаг, то была бы другая последовательность значений. Считается, что в MS SQL поле с автоинкрементом "помнит" последнее добавленное в него значение, и при добавления следующей записи даёт новое значение, уже с приращением. В Oracle методика немного другая ,но смысл тот же.


Что сбросить?

Что мне надо сделать , чтобы подсчёт начался с 1 опять?

gogzor, 
удали и создай поле в таблице или всю таблицу заново.
  

Ясно    , но както это не правильно

Всего лишь способ ускорить работу БД (чтобы потом не шерстить всю таблицу с целью поределить, существует ли уже в столбце значение id = 1 или 5467236.) Воспринимай это значение не как приятную взгляду и простую цифру 1, а как идентификатор (уникальную, но всего лишь метку).