Бобровски С. Oracle7 и вычисления клиент/сервер
| Вид материала | Литература |
- Дипломная работа студента 545 группы, 334.18kb.
- «sql*net», 239.02kb.
- Вопросы к экзамену по курсу "Компьютерные системы и сети", 25.77kb.
- Приложения литература, 256.14kb.
- Программа предназначена для управления бд по технологии «клиент-сервер», 26.71kb.
- Тема: 14. Введение технологии клиент сервер. Новые возможности и средства разработки., 1083.16kb.
- Iv-я Всероссийская научная конференция «Нечеткие системы, мягкие вычисления и интеллектуальные, 92.67kb.
- Вопросы для сдачи экзамена по ктп 2008 год, 51.83kb.
- Яковлев Владимир Леонидови, кафедра "Автоматизированные информационные системы" мгту, 2163.4kb.
- Задачи восстановление пропущенных значений в реляционных бд. 20. Oltp и olap. Многомерные, 28.62kb.
(Отформатировано для вывода на Epson LX-800)
Объем и структура курса
По курсу запланировано: один час лекций и три часа лабораторных занятий в неделю, а также курсовая работа. В курсовой работе студент (или бригада из двух студентов) должен выбрать любую, хорошо знакомую ему, предметную область - часть реального мира, данные о которой он хочет хранить в базе данных на компьютере. Это может быть небольшой магазин (ларек), торгующий любой продукцией (например, аудио- или видио-кассетами); пошивочное ателье; пункт проката; зоопарк; склад; коллекция (монет, марок, вин и др.); справочная вокзала (железнодорожного, речного, морского или аэро); аптека, лекарственные растения, гостиница, продажа квартир и т.п. Затем он должен спроектировать для этой предметной области базу данных и создать ее на SQL-сервере кафедры ВТ во время лабораторных занятий. Начать же лабораторные занятия он должен со знакомства с основами языка SQL, являющегося международным стандартом языка баз данных.
Занятия будут проводиться с использованием СУБД Oracle8, являющейся лучшей профессиональной СУБД. Желающие увеличить время на изучение этой СУБД и имеющие дома ПК с достаточными ресурсами (х486 или выше, не менее 16 МВ ОЗУ, 200 МВ дискового пространства и установленный Windows 95 или Windows NT) могут переписать на кафедре пакет Personal Oracle 7.3 или Personal Oracle8.
В следующем семестре, в рамках дисциплины "Проектирование приложений к базам данных", студент (бригада) должны создать приложение для своей базы данных, т.е. спроектировать и построить различные формы для ввода, модификации и просмотра данных, а также отчеты для вывода разнообразной документации.
Литература
1. Бобровски С. Oracle7 и вычисления клиент/сервер. — М.: ЛОРИ, 1995. - 652 с.
2. Грабер М. Введение в SQL. — М.: ЛОРИ, 1996. - 380 с.
3. Дейт К.Дж. Введение в системы баз данных. - 6-изд. — К.: Диалектика, 1998. - 784 с.
4. Кириллов В.В. Основы проектирования реляционных баз данных. Учебное пособие. — СПб.: ИТМО, 1994. - 88 с. mo.ru, rum.ru.
5. Кириллов В.В., Громов Г.Ю. Структуризированный язык запросов (SQL). Учебное пособие. — СПб.: ИТМО, 1995. - 92 с. mo.ru, rum.ru.
6. Кириллов В.В., Громов Г.Ю. Краткий справочник по Oracle7. Электронное учебное пособие. — ИТМО, 1997. mo.ru.
7. Компания Advanced Information Systems и др. Oracle8. Энциклопедия пользователя.: К. — ДиаСофт, 1998. - 864 с.
8. Мейер М. Теория реляционных баз данных. — М.: Мир, 1987. - 608 с.
9. Ричардс Майкл и др. Oracle 7.3. Энциклопедия пользователя. — К: ДиаСофт, 1997. - 832 с.
10. Сингх Лэйв. Oracle 7.3. Пособие разработчика. — К: ДиаСофт, 1997. - 736 с.
11. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., — М.: Мир, 1985. Кн. 1.- 287 с.: Кн. 2. - 320 с.
1. Введение
Существует множество определений понятия "База данных" (БД) иногда совсем не похожих друг на друга. Воспользуемся одним из них: «База данных — это файлы, снабженные описанием хранимых в них данных и находящиеся под управлением специальных программных комплексов, называемых "Системы управления базами данных" (СУБД)».
Сколько должно быть этих файлов, кто и как должен распределять между ними данные, как создать понятные СУБД описания данных, как обеспечить безопасность хранимых данных? Эти и многие другие вопросы будут изучаться в этом курсе. Но сначала будет рассмотрен достаточно большой пример.
Дело в том, что человеку, не знакомому с БД, трудно без примеров объяснить, что такое данные и их описание, как устроена СУБД и как она управляет данными. Конечно, таким примером может стать описание любой базы данных, функционирующей под управлением какой-либо СУБД. Однако, как было сказано выше, в этом курсе нам надо познакомиться и с методами проектирования БД, поэтому целесообразнее потратить время на создание своей иллюстрационной БД. Для этого спроектируем БД «Учебный процесс», в которой будут хранится сведения необходимые для Деканатов, Учебной части, Отдела кадров, Планового отдела (распределение средств за обучение между кафедрами), Бухгалтерии (стипендия), Выпускающих кафедр и др.
При построении моделей мы будем опираться в основном на здравый смысл, а не на теоретические положения и рекомендации, которые будут рассмотрены в следующих разделах курса. Желающие раньше познакомиться с ними могут воспользоваться, например, учебным пособием [4].
2. Введение в проектирование баз данных
2.1. Об этапах проектирования
Процесс проектирования состоит из трех основных этапов:
- получение технического задания или создание описания предметной области;
- построение инфологической модели базы данных;
- создание даталогической модели базы данных.
Сначала необходимо получить от заказчика техническое задание на разработку базы данных или при инициативной ее разработке (например, в курсовом проекте) подробно описать выбранную предметную область — часть реального мира, данные о которой нужно хранить в создаваемой базе данных.
Затем создается обобщенное, не привязанное к каким-либо компьютерам и СУБД, описание предметной области (наборы данных, их типов, длин, связей и т.п.), называемое инфологической моделью.
Наконец, выбирается СУБД, под управлением которой должна функционировать база данных, и создается ее даталогическая модель.— инфологическая модель, переведенная на язык выбранной СУБД.
2.2. Описание предметной области «Учебный процесс»
2.2.1. Учебные планы и выпускающие кафедры
По инициативе одной или нескольких кафедр вуза, подготавливающих документы для обоснования открытия на ее (их) базе новой специальности или бакалаврского направления, Ученый совет вуза обращается в министерство с просьбой о выдаче лицензии на право подготовки по этой специальности (направлению). Среди этих документов существует и предлагаемый вузом учебный план, составленный на основе соответствующего государственного образовательного стандарта (ГОС), содержащего государственные требования к минимуму содержания и уровню подготовки выпускников. В «шапках» этих планов, например, указано:
УЧЕБНЫЙ ПЛАН
ПОДГОТОВКИ ИНЖЕНЕРОВ ПО СПЕЦИАЛЬНОСТИ
220100 "ВЫЧИСЛИТЕЛЬНЫЕ МАШИНЫ, КОМПЛЕКСЫ, СИСТЕМЫ И СЕТИ"
Специализация 220111 — "Открытые информационно-вычислительные системы"
или
УЧЕБНЫЙ ПЛАН
ПОДГОТОВКИ БАКАЛАВРОВ ПО НАПРАВЛЕНИЮ
552800 "ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА"
или
УЧЕБНЫЙ ПЛАН
ПОДГОТОВКИ МАГИСТРОВ ПО НАПРАВЛЕНИЮ
552800 "ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА"
Специализация 552811 — "Базы данных"
С выполненными по принятой в вузе форме учебными планами вы можете познакомиться на выпускающих кафедрах — кафедрах, которым поручен набор абитуриентов и их подготовка по соответствующей специальности или направлению, по которым получена лицензия.
Учебные планы и программы обучения по специальностям, бакалаврским и магистерским направлениям непрерывно модифицируются с целью их улучшения и привязки к текущему моменту. Выпускающие кафедры пытаются внедрить новые (модифицированные) дисциплины и другие нововведения по мере их появления и нередко студент начинает обучение по учебному плану, который действовал на момент его поступления в университет, затем плавно переходит на смесь этого и нового планов (так называемый, переходной учебный план), затем на новый переходной учебный план и т.д., заканчивая обучение совсем по другому учебному плану. Кроме того, в учебных планах специально оставлено место для ежегодной модификации (Дисциплины по выбору студентов или выпускающих кафедр, Факультативы и т.п.) и нередко студенты изучают дисциплины, названия, объемы и другие атрибуты которых отличаются от дисциплин утвержденных учебных планов.
Поэтому планирование учебного процесса в студенческих потоках и группах осуществляется с помощью рабочих учебных планов, ежегодно составляемых и утверждаемых на основании старых, переходных и новых учебных планов с учетом контингента обучаемых. Некоторым студентам разрешено создавать индивидуальный учебный план, который также может ежегодно корректироваться.
В рабочих учебных планах, составляемых в конце предшествующего учебного года на следующий учебный год, приведены для каждого направления, специальности и специализации актуальные на текущий момент дисциплины и номера студенческих групп (подгрупп), которые должны изучать эти дисциплины. В зачетных книжках студентов и ряде документов деканатов фиксируется набор изучаемых каждым студентом дисциплин, а также те оценки, которые они получили за курсовые проекты (работы), на зачетах и экзаменах.
Следовательно, единственными актуальными документами, в которых прописаны реально изучаемые студентами дисциплины, являются рабочие и индивидуальные планы и весь процесс обучения должен быть привязан к ним.
На рис. 2.1 приведен рабочий план для студентов 3-го курса специальности 220100.
В плане в столбце "Кафедра" дана аббревиатура кафедры, которой поручено проведение занятий по дисциплине, с названием указанным в столбце "Дисциплина". В следующих столбцах приведены числа часов запланированных на лекции (Лек), лабораторные (Лаб) и практические (Прак) занятия, а также на самостоятельную работу студента (СРС) над материалом дисциплины (подготовка к лекциям, лабораторным и практическим занятиям, выполнение домашних заданий, курсовых проектов и работ, ...). Далее (Конт) указан вид контроля (экзамен, зачет, КП или КР) и индекс (Инд) дисциплины, т.е. принадлежность ее к одному из следующих циклов дисциплин: "Гуманитарные и социально-экономические дисциплины" (ГСЭ), "Естественно-научные дисциплины" (ЕН), "Дисциплины направления" (ДН), "Общепрофессиональные дисциплины" (ОПД), "Специальные дисциплины" (СД), "Дисциплины специализации" (ДС) и "Дополнительные виды обучения и факультативы" (ДФ). Если по дисциплине запланировано N видов контроля, то в рабочем плане для нее отводится N строк.
При этом одна выпускающая кафедра может вести подготовку по нескольким специализациям (одной или нескольких специальностей), бакалаврским и магистерским направлениям, а также разным формам обучения (дневной, вечерней или заочной). Аналогично, по одной специализации (одному направлению) могут вести подготовку несколько выпускающих кафедр.
Как правило, одна студенческая группа "принадлежит" одной выпускающей кафедре и подготавливается по одной специализации или одному направлению. Однако встречаются случаи, когда в группе обучаются студенты (бакалавры или магистры) разных специализаций (они вместе обучаются по общим для специализаций дисциплинам и разделяются на подгруппы по остальным).
Схематично связь между группами (подгруппами), кафедрами и специализациями (направлениями) на 1998/99 учебный год может быть показана следующим образом (рис. 2.2).
2.2.2. Сведения об обучаемых
О каждом из обучаемых (студентов, бакалавров, магистров, аспирантов и т.п.) требуется хранить в базе данных достаточно много сведений. Для студентов, бакалавров и магистров часть из них определено в учебной карточке студента (рис. 2.3).
Кроме того, сведения о студенте существуют и в таких документах:
ЛИЧНЫЙ ЛИСТОК ПО УЧЕТУ КАДРОВ,
ЗАЧЕТНО - ЭКЗАМЕНАЦИОННЫЕ ВЕДОМОСТИ,
СВЕДЕНИЯ О ТЕКУЩЕЙ УСПЕВАЕМОСТИ (АТТЕСТАЦИИ),
ПРИКАЗ О ЗАЧИСЛЕНИИ НА СТИПЕНДИЮ,
РАСПИСАНИЕ ЗАНЯТИЙ,
...
Ограничимся в данном примере только следующими ниже данными о студентах (бакалаврах и магистрах):
1. Номер зачетной книжки (НЗК).
2. Фамилия.
3. Имя.
4. Отчество.
5. Дата рождения.
6. Пол.
7. Признак: 1 — для студентов из дальнего зарубежья (иностранцев) и 0 — для остальных.
8. Группы, в которых обучался студент.
9. Номера рабочих (индивидуальных) планов и деканаты — соавторы этих планов.
11. Изменения состояния обучаемого (академический отпуск, повторное обучение и т.п.).
12. Номера приказов об изменении каких-либо предшествующих данных.
При этом ряд данных должен быть снабжен датой, указанной в приказе о их изменении (например, о переводе студента на следующий курс или об окончании академического отпуска).
Наконец, будем еще хранить в создаваемой базе сведения об оценках, получаемых по курсовым зачетам и экзаменам, пока не затрагивая данные о текущей аттестации.
Для контрактных студентов (т.е. студентов, полностью возмещающих затраты на обучение) необходимо также знать: подразделение, заключившее договор на платное обучение, и номер договора; начало и конец действия договора; ежегодную величину оплаты (в МРОТ или $) по договору; различные исключения по оплате; сведения о внесении в кассу ИТМО средств за платное обучение и другие услуги.
2.3. Инфологическая модель базы данных "Учебный процесс"
2.3.1. О моделях данных
Как правило все данные связаны между собой. (Со студентом связано множество дисциплин и их преподавателей, один номер зачетной книжки и одна стипендия ...). Наличие множества связей требует создания определенной структуры описания данных, которые называются моделями данных.
Исторически первой появилась иерархическая модель, например
== Факультет ==> группы ==> студенты ==> дисциплины ==> преподаватели ==
Однако оказалось, что поиск данных от листьев к корню выполняется значительно медленнее чем от корня к листьям. (быстрый запрос — преподаватели обслуживающие факультет, медленный запрос — количество неуспевающих студентов на каждом факультете).
Создали сетевую модель (связанные кольца двухуровневых деревьев), но она оказалась настолько сложной что проектированием данных могли заниматься только высококвалифицированные специалисты.
В 70 г. была предложена реляционная (relation — отношение, связь) или иначе табличная модель данных. В дальнейшем будем ориентироваться только на эту модель данных, обладающую следующими основными свойствами.
1. Данные воспринимаются пользователями как таблицы (и никак иначе).
2. Каждая таблица состоит из однотипных строк и имеет уникальное имя.
3. Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего.
4. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы.
5. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы).
6. Полное информационное содержание базы данных представляется в виде явных значений данных и такой метод представления является единственным. В частности, не существует каких-либо специальных "связей" или указателей, соединяющих одну таблицу с другой.
7. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой их строки или любого набора строк с указанными признаками.
2.3.2. Первая попытка проектирования
В выбранной модели все хранимые данные должны быть размещены в одной или нескольких таблицах. Можно ли для этой цели использовать единственную таблицу, так называемое, универсальное отношение ?
Принципиально можно, но в этой таблице данные почти всех столбцов будут многократно повторятся (возникнет избыточность). Так для каждого студента одной и той же группы будут повторяться названия специализации, выпускающей кафедры и изучаемых дисциплин; каждая из дисциплин рабочего плана будет предваряться всеми атрибутами студента (Фамилия, Имя, Отчество, ...) и т.п.
Вследствие избыточности могут возникать проблемы при изменении данных.
Аномалии обновления. Если, например, студентка поменяла фамилию, то при изменении в таблице множества экземпляров ее фамилии можно «забыть» обновить некоторые строки со старой фамилией и тем самым «потерять» какие-либо данные об успеваемости этой студентки.
Аномалии включения. В таблицу нельзя внести данные о том, по каким рабочим учебным планам будут обучаться студенты в следующем учебном году, так как у вуза нет данных о будущих студентах первого курса, да и неясно, кто из студентов старших курсов перейдет на следующий курс, без изменения специализации.
Аномалии удаления. Обратные проблемы возникают при необходимости удаления из таблиц сведений о каком-либо студенте или о дисциплинах рабочего плана.
Многие проблемы исчезнут, если выделить в отдельные таблицы сведения о кафедрах, специализациях, рабочих планах, студентах и т.д. Такое разбиение таблицы на несколько таблиц, обладающих лучшими свойствами при включении, изменении и удалении данных, называется нормализацией. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных (например, если в таблице одновременно существует и старая, и новая фамилия студентки).
2.3.3. Вторая попытка проектирования
Анализ определенных выше объектов и атрибутов, а также показанных выше аномалий, позволяет выделить сущности проектируемой базы данных, которые можно разделить на независимые (стержневые) и зависимые (ассоциации, характеристики и обозначения) [4].
В процессе определения атрибутов сущности (столбцов таблицы) необходимо обязательно определить их возможные и первичные ключи:
Ключ или возможный ключ — минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности (строку таблицы). Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Первичный ключ — любой из возможных ключей (лучше несоставной и целочисленный). Например, если считать, уникальными для каждого студента атрибуты номер зачетной книжки (НЗК) и сочетание
"Фамилия, Имя, Отчество, Рождение, Пол", то для выбора конкретного студента можно использовать любой из этих возможных ключей, но лучше целочисленный — НЗК.
Для зависимых сущностей необходимо рассмотреть еще одно понятие — внешний ключ. Это атрибут или набор атрибутов зависимой (дочерней) таблицы, с помощью которого (которых) производится ссылка на первичный ключ другой (родительской) таблицы, т.е. как бы производится связывание таблиц. При этом родительской может быть как независимая, так и зависимая таблица — цепочка связей между таблицами ничем не ограничивается и может иметь чрезвычайно сложную структуру. Ввод в СУБД правильного описания первичных и внешних ключей включает механизмы ограничений базы данных, не позволяющие удалить строку с тем значением первичного ключа, на который ссылается какой-либо внешний ключ, или ввести строку с таким значением внешнего ключа, которое отсутствует среди значений первичного ключа.
Кроме описания атрибутов каждой таблицы (включая ключи) необходимо указать также те ограничения на значения и форматы данных в отдельных столбцах или их сочетаниях, которые позволят задействовать в СУБД дополнительные процедуры обеспечения целостности (правильности и непротиворечивости) хранимых данных.
2.3.3.1. Независимые сущности (таблицы)
1. Студенты (Номер, НЗК, Фамилия, Имя, Отчество, Рождение, Пол, Иностранец, Пользов, Измен).
Таблица отводится для хранения неизменных (кроме редкого изменения фамилии) данных об обучаемых (студентах, бакалаврах, магистрах, аспирантах и докторантах). Остальные данные, которые должны изменяться по мере перехода обучаемого с курса на курс или по другим причинам будут размещены в зависимой таблице Ученик.
Здесь НЗК и Рождение — номер зачетной книжки и дата рождения обучаемого, а Иностранец — содержат 1 для обучаемых из "дальнего зарубежья" и 0 — в остальных случаях. Тип данных атрибута Рождение — дата, а атрибутов Иностранец и НЗК — целые числа, длиной одна и шесть цифр, соответственно.
Так как у аспирантов и докторантов нет зачетных книжек и, следовательно, НЗК, а сочетание фамилии, имени, отчества, даты рождения и пола достаточно громоздко и теоретически не является уникальным, то для уникальной идентификации строки таблицы Студенты в нее целесообразно добавить целочисленный атрибут Номер, объявив его первичным ключом. Учитывая, что в ИТМО ежегодно поступает не более 2000 обучающихся, длину номера может ограничить пятью цифрами и для удобства размещения в документах сделать постоянной (от 10000 до 99999). Каждый новый номер целесообразно получать с помощью процедуры, наращивающей последний существующий номер на единицу.
Фамилия, Имя и Отчество — текстовые атрибуты, длина которых может быть ограничена значениями 20, 15 и 20 символов, соответственно.
Пользов и Измен — идентификатор пользователя, который ввел эту строку или исправил ее содержание, и время ее изменения (дата и время с точностью до секунд); это делается для повышения ответственности пользователей, вводящих и (или) изменяющих данные. Формат этих значений: целое число длиной до четырех цифр и дата, соответственно. Ввод Пользов и Измен должен производится автоматически и они не могут быть скорректированы пользователями.
При вводе новых или изменении атрибутов существующих строк необходимо обеспечить уникальность НЗК и информировать о появлении дубликата существующего сочетания "НЗК, Фамилия, Имя, Отчество, Рождение, Пол, Иностранец". Кроме того, необходимо, чтобы значения столбца Пол принадлежали набору "м" или "ж", а дата рождения была в пределах от (Текущая дата — 40 лет) до (Текущая дата — 15 лет), первые буквы фамилии, имени и отчества были большими, а остальные — малыми.
2. Уч_года (Уч_год, Начало, Конец).
Таблица отводится для хранения названий учебных годов (Уч_год в формате ’ГГГГ/ГГГГ’) и дат их начала (Начало) и окончания (Конец).
Первичным ключом этой таблицы является Уч_год.
При вводе новых или изменении атрибутов существующих строк необходимо отслеживать, чтобы:
- дата начала была не больше, чем дата окончания учебного года;
- сочетание "Уч_год, Начало, Конец" было уникальным.
3. Уч_циклы (Индекс, Имя_цикла).
Таблица отводится для хранения индексов (например, ЕН) и названий (Естественно-научный) учебных циклов. Это текстовые атрибуты, длиной до трех и сорока пяти символов.
В таблице два возможных ключа, из которых в качестве первичного ключа целесообразно выбрать короткий Индекс.
Эта таблица достаточно проста и должна содержать мало данных (в пределах одного экрана), правильность ввода и изменения отслеживается визуально.
4. Факультеты (Факульт, Факультет).
Таблица отводится для хранения аббревиатур и названий факультетов. Здесь Факультет — название факультета (например, Оптический факультет или Факультет компьютерных технологий и управления), а Факульт — аббревиатура названия факультета (например, ИФ или КТиУ). Это текстовые атрибуты длиной до пятидесяти и пяти символов, соответственно.
В таблице два возможных ключа, из которых в качестве первичного ключа целесообразно выбрать короткий Факульт.
Таблица достаточно проста и должна содержать мало данных (в пределах одного экрана), правильность ввода и изменения отслеживается визуально.
5. Специал (Специал, Статус, Имя_спец, Пользов, Измен).
Таблица отводится для хранения номеров (Специал) и полных названий (Имя_спец) специальностей, направлений и специализаций, а также статуса (Статус) обучаемого (студент, бакалавр, магистр, аспирант или докторант). Например, "220100, студент, Вычислительные машины, комплексы, системы и сети", "552800, бакалавр, Информатика и вычислительная техника" или "552800, магистр, Информатика и вычислительная техника". Это текстовые атрибуты длиной до шести, ста двадцати и девяти символов, соответственно.
Пользов и Измен — см. описание этих полей в таблице 1. Студенты.
Как показано выше, аналогичным бакалаврским и магистерским направлениям присваиваются одинаковые номера и названия, поэтому в качестве первичного ключа придется использовать один из двух возможных составных ключей: Специал, Статус или Имя_спец, Статус. Используем короткий — Специал, Статус.
При вводе новых или изменении атрибутов существующих строк необходимо обеспечить уникальность сочетания "Специал, Статус, Имя_спец".
6. Имя_дисц (Кор_дисц, Имя_дисц, Пользов, Измен).
Таблица отводится для хранения сокращенных и полных названий дисциплин. Здесь Кор_дисц — короткое, а Имя_дисц — полное название дисциплины. В таблице два возможных ключа, из которых в качестве первичного ключа целесообразно выбрать короткий — Кор_дисц. Это текстовые атрибуты длиной до шестнадцати и ста двадцати символов, соответственно.
Пользов и Измен — см. описание этих полей в таблице 1. Студенты.
При вводе новых или изменении атрибутов существующих строк необходимо обеспечить уникальность сочетания "Кор_дисц, Имя_дисц".
7. Вид_отд (Вид_отд, Имя_вида_отд).
Таблица отводится для хранения кода (Вид_отд) и названия (Имя_вида_отд) вида отдела, например, "1, Административные", "3, Учебные" и т.п. Из двух ее возможных ключей (Вид_отд и Имя_вида_отд) выбирается короткий — Вид_отд. Вид_отд целочисленный атрибут длиной до двух цифр, а Имя_вида_отд — текстовый атрибут длиной до сорока символов.
Эта таблица достаточно проста и должна содержать мало данных (в пределах одного экрана), правильность ввода и изменения которых отслеживается визуально.