Есть БД, в ней таблица с ~30 атрибутами, они вроде полностью зависят от первичного ключа, но с таким кол-вом артрибутов не очень удобно работать. Помоги те пожалуйста 




Это сообщение отредактировал(а) Viktor059 - 4.9.2010, 19:09

Присоединённый файл ( Кол-во скачиваний: 2 )
 Microsoft_Office_Access_2007.rar 20,89 Kb

Сконевертируйте бд в Access 2003. 2007 не у всех установлен.

вот для 2003

Присоединённый файл ( Кол-во скачиваний: 2 )
 Microsoft_Office_Access_2003.rar 17,09 Kb

вот пока что смог сделать, посмотрите пожалуйста

Присоединённый файл ( Кол-во скачиваний: 6 )
 2003_2007.rar 48,57 Kb

может так:
1 можно удалить в "контактах" и "информация колледж" ключевые поля, заменив их на "студент", как в "егэ"
2 можно сделать отдельную таблицу "формы обучения" - забить туда "очное бюджет", "очное платное", "заочное ...", и остальные три пункта наверное тоже можно добавить и сделать ключом от "формы обучения" к ид новой таблицы
3 сотовый студента перенести в "контакты"
4 фио родителей можно объединить
5 какая разница в "пред. месте обуч" между наименованием и полным названием - первое аббревиатура, она действительно нужна?

или надо было что-то другое

Посмотрел на то, что "сделано". Вердикт однозначный - выбросить и начать заново. 

О какой нормализации может идти речь, если не выделены сущности? соответственно всё остальное тоже не сделано. Ты просто взял кучку того, что есть, соскрёб в несколько табличек "по понятиям", и пририсовал связи.

Мой тебе совет - начинай по-новой. Но сперва почитай, как собственно она выполняется - нормализация. Вернее, не нормализация - проектирование БД. С чего начинается, какие этапы выполняются, что делается на каждом из них и т.д.

Akina, ну что ж сделаешь я пока что учусь

aleksh, спасибо, учту ваши советы

Вот я и говорю, в каком направлении надо двигаться.
Ибо если ты продолжишь развивать то, что есть, тебя ждёт поле с граблями.

Предлагаю следующие шаги:
1. Выделенить объекты. 
2. Ппределить связи между объектами с мощностью связей: один-к-одному, один-ко-многим. 
3. Определить состав атрибутов объектов.
4. Определить набор справочников. В справочники стоит перевести все текстовые поля, которые содержат повторяющиеся значения.
5. Копозиция и декомпозиция объектов.

На 5м шаге необходимо перепроверить всю схему бд. Кое где объекты объединятся в одну таблицу, где-то еще выделятся объекты.
Например, адерс отделять от студента не всегда удобно. Но, если он повторяется у родителей, то возможно, имеет смысл это сделать, для обобщения его обработки.

вот это очень важное замечание
Viktor059, может действительно имеет смысл пересмотреть дизайн бд? на сколько понимаю, база для заполнения уже есть, для начала хорошо бы ее изучить на предмет часто повторяемых значений - вот как с адресом

Да нечего тут изучать. ТС просто не знаком с предметной областью, его схема не предусматривает массы реалий. Вот несколько, навскидку:
Есть таблица групп... что он будет делать с данными. если студент переведётся в другую группу? А в конце учебного года и начале следующего?
Есть таблица студентов... что он будет делать, если студент поменяет паспорт? если он до этого учился в двух УЗах, а это третий? а когда студентка выйдет замуж и сменит фамилию?
Вообще - как с такой схемой хранить движение и историю? а всё это нужно хранить.