Проектирование бд в erwine

[LifeNot]

Добрый вечер никак не доходит как правильно можно спроектировать бд помогите пожалуйста

Тема вопроса "Спроектировать базу данных для выдачи справок о том, какие фильмы идут в разных городах. В отношения должны быть включены следующие атрибуты: город, название кинотеатра, название фильма, ФИО директора кинотеатра, стоимость билета, сеанс, адрес кинотеатра, категория фильма, аннотация фильма. "

снизу вложил ервин

[pu4koff]

У всех сущностей отсутствует главный ключ, т.е. некий идентификатор, который уникален для любой из записей таблицы. Ключи бывают естественными и суррогатными. Естественные - когда из реального мира можно что-то взять за уникальный ключ. Суррогатный - подходящего ключа нет, поэтому просто добавляется числовое поле с автоматической генерацией уникального внутри таблицы значения.
Берем таблицу город. Поле только одно - Название. Можно ли по названию идентифицировать город? Я знаю как минимум три города с названием "Каменка". Только по названию потом выбрать нужную Каменку мы не сможем и другого поля, чтобы несколько сгруппировать в уникальный ключ, нет. Придётся добавить ИД_города. Это у нас будет Primary Key, на схеме будет в пустующей сейчас ячейке над полем "Название" и с припиской (PK).
Дальше у нас идёт "Кинотеатр", кинотеатр должен хранить в каком городе находится, а значит нужно протянуть связь от Города к Кинотеатру. Автоматом в кинотеатр добавится Foreign Key на ключ Города, т.е. будет еще строчка ИД_города (FK). Дальше можно сделать составной ключ для Кинотеатра. Врядли в одном городе будет два одноименных кинотеатра. Вот пусть город и название будут ключем Кинотеатра. Связь между таблицами сделается в итоге идентифицирующей и таблица нарисуется со скругленными углами. И вот как-то так дальше строить связи между оставшимися таблицами и выбирать ключи для них.

[LifeNot]

Сообщение от pu4koff

У всех сущностей отсутствует главный ключ, т.е. некий идентификатор, который уникален для любой из записей таблицы. Ключи бывают естественными и суррогатными. Естественные - когда из реального мира можно что-то взять за уникальный ключ. Суррогатный - подходящего ключа нет, поэтому просто добавляется числовое поле с автоматической генерацией уникального внутри таблицы значения.
Берем таблицу город. Поле только одно - Название. Можно ли по названию идентифицировать город? Я знаю как минимум три города с названием "Каменка". Только по названию потом выбрать нужную Каменку мы не сможем и другого поля, чтобы несколько сгруппировать в уникальный ключ, нет. Придётся добавить ИД_города. Это у нас будет Primary Key, на схеме будет в пустующей сейчас ячейке над полем "Название" и с припиской (PK).
Дальше у нас идёт "Кинотеатр", кинотеатр должен хранить в каком городе находится, а значит нужно протянуть связь от Города к Кинотеатру. Автоматом в кинотеатр добавится Foreign Key на ключ Города, т.е. будет еще строчка ИД_города (FK). Дальше можно сделать составной ключ для Кинотеатра. Врядли в одном городе будет два одноименных кинотеатра. Вот пусть город и название будут ключем Кинотеатра. Связь между таблицами сделается в итоге идентифицирующей и таблица нарисуется со скругленными углами. И вот как-то так дальше строить связи между оставшимися таблицами и выбирать ключи для них.

Так это я сделаю, у меня большие проблемы с выбором ключей где главный ключ, а где побочный. Еще не догоняю что нужно вписать в цену билета и в аннотацию фильма .

[pu4koff]

Главный ключ - это полностью уникальный ключ, лучшим образом подходящий для идентификации записи в таблице. В реальной разработке в большинстве своём используют суррогатные ключи с автоинкрементом, т.е. просто некие ID, которые никто вручную не указывает и которые ничего не значат. Остальные ключи нужны для ускорения выполнения запросов, могут быть неуникальными.
Цена билета наверно зависит от фильма и от кинотеатра. Для учебного проекта такого составного главного ключа хватит. Ну, и не забудьте добавить саму стоимость билета.
Вообще таблица - это сущность. Атрибут - это поле таблицы. Так что может и не нужно выносить в отдельную сущность аннотацию? А так от фильма идентифицирующую связь к аннотации и там один атрибут собственно сама аннотация.
Делайте что получается, а там к преподу, который скажет как ему нужно. Тут нет правильно и неправильно. есть - устраивает препода или нет