Модель данных (реляционная)

1.2 Модель данных (реляционная)

Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц.

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".

Будучи математиком по образованию Э. Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.).

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

Доменом называется множество атомарных значений одного и того же типа. Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву"). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, а степени n – n-арным.

Каждое отношение обладает хотя бы одним возможным ключом, поскольку по меньшей мере комбинация всех его атрибутов удовлетворяет условию уникальности. Один из возможных ключей (выбранный произвольным образом) принимается за его первичный ключ. Остальные возможные ключи, если они есть, называются альтернативными ключами.

Вышеупомянутые и некоторые другие математические понятия явились теоретической базой для создания реляционных СУБД, разработки соответствующих языковых средств и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Однако для массового пользователя реляционных СУБД можно с успехом использовать неформальные эквиваленты этих понятий:

Отношение – Таблица (иногда Файл),

Кортеж – Строка (иногда Запись),

Атрибут – Столбец, Поле.

При этом принимается, что "запись" означает "экземпляр записи", а "поле" означает "имя и тип поля".

1.4 Среда разработки

Курсовой проект был выполнен на языке программирования Borland Delphi 7.0. Таблицы разрабатывались в приложении Database Desktop. Для более понятного и удобного интерфейса использовались такие компоненты как DBGrid, DBNavigator, Splitter. Запросы создавались с помощью компонента Query. А отчёты на основе запросов с помощью компонентов RvQueryConnection и RvProject в приложении Rave Designer.

1.5 Требования к программе

Программа совместима со всеми операционными системами Windows. Для работы данной программы необходим ПК, имеющий следующие системные требования:

- Операционная Windows любой версии;

- Процессор 200 MHz и выше;

- Емкость ОЗУ не ниже 32 Мб;

- Дисковод 3,5” или CD-ROM;

- 16 Мбайт свободного места на жестком диске;

2          ПРОЕКТИРОВАНИЕ ЗАДАЧИ

2.1 Организация данных

В курсовом проекте используется база данных состоящая из четырёх таблиц. Структуры таблиц приведены в таблицах 1.1, 1.2, 1.3, 1.4

- Abitur (Данные о абитуриентах);

- Spec (Данные о специальностях);

- Ekzam (Данные о экзаменах);

- Kurs (Данные о абитуриентах, посещающих курсы);

Таблица 1.1 – Структура таблицы Abitur.

Таблица 1.2 – Структура таблицы Spec.

Таблица 1.3 – Структура таблицы Ekzam.

Таблица 1.4 – Структура таблицы Kurs.

Связи таблиц показаны на рисунке 2.1.

Рис. 2.1 Связи таблиц.

Поле Nazvanie в таблице Abitur ключевое. В нём хранятся данные о названиях специальностей. В поле Spec в таблице Abitur хранятся данные о специальности, на которую поступает конкретный абитуриент.

Похожие работы

Социально-педагогические технологии в работе с приёмными родителями, опекунами и попечителями (на примере г. Биробиджана)

Скачать

37210

0

0

... попечителями, либо принять детей, оставшихся без попечения родителей, в семью на воспитание. Учет должен вестись в порядке, определяемом Правительством РФ.   1.2 Социально-педагогические технологии в работе с приёмными родителями, опекунами и попечителями   Процесс взаимной адаптации замещающей семьи и приемного ребенка можно представить как сложную динамику образования новой семейной системы, ...

Обращения граждан в федеральные органы исполнительной власти

Скачать

216381

0

9

... ведения статистики и аналитической работы у каж­дого ведомства свои, что делает крайне трудной, даже невозможной подготовку общих отчётов по обращениям граждан в федеральные органы исполнительной власти. В-четвёртых, при регистрации обращений учитывается в основном их тематическая направленность, но, как правило, не учитывается их вид по со­держанию, поэтому заявления, жалобы, предложения не ...

Социально-педагогическая деятельность с детьми, оставшимися без попечения родителей

Скачать

61268

1

0

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

Применение информационных систем в колледже

Скачать

51581

3

12

... ДЕЯТЕЛЬНОСТИ 6.1  Концептуальное проектирование Целью работы является оптимизация деятельности анализируемого подразделения и поиск путей повышения его устойчивости с помощью создания автоматизированных информационных систем. Задача администратора такой АИС заключается в своевременном принятии документов, представлении их руководителю отдела, контролем над работой, сроками сдачи, ...