- •1 Обследование предметной области
- •2 Концептуальное проектирование
- •3 Инфологическое проектирование
- •3.1 Модель «сущность-связь»
- •3.2 Классификация связей
- •4 Реляционная модель базы данных
- •4.1 Функциональные зависимости между атрибутами
- •4.2 Выбор ключей
- •4.3 Определение отношений между таблицами
- •4.4 Нормализация отношений
- •5 Даталогическое проектирование
- •5.1 Состав таблиц базы данных
- •5.2 Средства поддержания целостности
- •6 Запросы к базе данных
- •7 Разработка механизмов защиты данных от несанкционированного доступа
- •8 Требования к техническому обеспечению
- •9 Инструкция по использованию бд
- •9.1 Вызов программы
- •9.2 Экранные формы
- •9.3 Описание отчетов
- •Заключение
- •Список используемых источников
- •Приложения
- •Приложение а. Er-диаграмма
- •Приложение б. Экранные формы
- •Приложение в. Запросы
- •Приложение г. Отчеты
3.2 Классификация связей
В реальных базах данных информация размещается в нескольких таблицах. Таблицы при этом связаны семантикой информации. В реляционных СУБД для указания связей таблиц производят операцию их связывания. Это повышает достоверность хранимой в базе информации, т. к. СУБД контролирует целостность данных, вводимых в базу в соответствии с установленными связями.
Установление связей облегчает доступ к данным при выполнении операций: поиск, просмотр, редактирование, выборка и подготовка отчета, т.к. обеспечивается обращение к любым полям связанных таблиц.
Между таблицами могут устанавливаться:
- бинарные связи;
- тернарные связи;
- n-арные связи.
При связывании двух таблиц выделяют основную и подчиненную таблицы (родительскую и дочернюю). Логическое связывание таблиц производится с помощью ключа связей. Поля основной таблицы могут быть простыми и ключевыми. Поля связей дополнительной таблицы чаще всего ключевые. В зависимости от того, как определены поля связи основной и дополнительной таблиц (как относятся ключевые поля с полями связи), устанавливаются виды связей:
- 1:1 (один к одному);
- 1:М (один ко многим);
- М:1 (многие к одному);
- М:М (многие ко многим).
Связь вида 1:1 образуется, если все поля связи родительской и дочерней таблиц являются ключевыми. Поскольку значения в ключевых полях двух таблиц не повторяются, обеспечивается взаимно-однозначное соответствие записей из этих таблиц. Сами таблицы, по сути, здесь становятся равноправными.
Связь вида 1:М имеет место в случае, когда одной записи родительской таблицы соответствует несколько записей дочерней таблицы.
Связь М:1 имеет место в случае, когда одной ил нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы.
Связь М:М возникает в случаях, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы.
Аналогично связи 1:1, связь М:М не устанавливает подчиненность таблиц. На практике в связь обычно вовлечены несколько таблиц. При этом одна таблица может иметь различные виды связи с несколькими таблицами, образуя иерархию или «дерево связей» [4].
В данном курсовом проекте таблицы связаны связями вида 1:М (один ко многим). Например, таблица «факультеты» является родительской таблицей по отношению к дочерней таблице «кафедры». Эти таблицы связаны отношением 1:М с помощью ключа «код_факультета»
4 Реляционная модель базы данных
Недостатки иерархической и сетевой моделей привели к появлению новой, реляционной модели данных, созданной Коддом в 1970 году и вызвавшей всеобщий интерес. Реляционная модель была попыткой упростить структуру базы данных. В ней отсутствовали явные указатели на предков и потомков, а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы.
К сожалению, практическое определение понятия «реляционная база данных» оказалось гораздо более расплывчатым, чем точное математическое определение, данное этому термину Коддом в 1970 году. В первых реляционных СУБД не были реализованы некоторые из ключевых частей модели Кодда, и этот пробел был восполнен только впоследствии. По мере роста популярности реляционной концепции реляционными стали называться многие базы данных, которые на деле таковыми не являлись.
В ответ на неправильное использование термина «реляционный» Кодд в 1985 году написал статью, где сформулировал 12 правил, которым должна удовлетворять любая база данных, претендующая на звание реляционной. С тех пор двенадцать правил Кодда считаются определением реляционной СУБД. Однако можно сформулировать и более простое определение.
Реляционной называется база данных, в которой все данные, доступные пользователю, организованы в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами.
Приведенное определение не оставляет места встроенным указателям, имеющимся в иерархических и сетевых СУБД. Несмотря на это, реляционная СУБД также способна реализовать отношения предок/потомок, однако эти отношения представлены исключительно значениями данных, содержащихся в таблицах [6].
В реляционных базах данных (Relational Database System, RDBS) все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.
Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70‑х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.
Строки таблицы составлены из полей, заранее известных базе данных. В большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице соответствует одной записи. Положение данной строки может изменяться вместе с удалением или вставкой новых строк.
Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key).
Так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных.
Еще один крупный недостаток реляционных баз данных – это высокая трудоемкость манипулирования информацией и изменения связей [7].
