Проектирование базы данных «Учащиеся»

Миниcтерство образования и науки Российской Федерации

Государственное образовательное  учреждение высшего профессионального  образования

 «Восточно-Сибирский государственная академия культуры и

искусства»

КУРСОВАЯ РАБОТА

Проектирование базы данных «Учащиеся»

Выполнил: ________________

Проверил:_________________

Улан-Удэ 2012 г.

СОДЕРЖАНИЕ

ГЛАВА 1. ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ «УЧАЩИЕСЯ»

1. Понятие Базы данных и СУБД

1.2 Проектирование базы данных предметной области «Учащиеся»

1.2.1 Концептуальное проектирование 

1.2.2 Инфологическое проектирование

1.2.3 Реляционная модель БД

ГЛАВА 2. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ «УЧАЩИЕСЯ»

2.1 Анализ и выбор СУБД для разработки базы данных

2.2 Состав таблиц БД

Заключение

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ГЛАВА 1. ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ «УЧАЩИЕСЯ»

1.1 Понятие  Базы данных и СУБД

База данных — это набор сведений, относящихся к определенной теме или задаче, такой как отслеживание заказов клиентов или хранение коллекции звукозаписей. Цель любой информационной системы — обработка данных об объектах реального мира. Если база данных хранится не на компьютере или на компьютере хранятся только ее части, приходится отслеживать сведения из целого ряда других источников, которые пользователь должен скоординировать и организовать самостоятельно.

Создавая базу данных, пользователь стремится упорядочить информацию по различным признакам и быстро извлекать выборку с произвольным сочетанием признаков. Сделать это  возможно, только если данные структурированы.

Структурирование — это  введение соглашений о способах представления  данных.

Неструктурированными называют данные, записанные, например, в текстовом  файле.

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

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

СУБД используют для управления, создания и использования БД. СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:

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

В качестве СУБД для реализации базы данных была использована FIREBIRD. FIREBIRD имеет все необходимые средства для выполнения перечисленных выше функций.

(FirebirdSQL) — компактная, кроссплатформенная, свободная система управления базами данных (СУБД), работающая наGNU/Linux,Microsoft Windows и разнообразных Unix платформах.

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

Среди недостатков числятся отсутствие кеша результатов запросов, индексов fulltext для полнотекстового поиска.

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

Основные характеристики

Соответствие требованиям A.C.I.D: Firebird сделан специально, чтобы удовлетворять требованиям "атомарности, целостности, изоляции и надежности" транзакций ("Atomicity, Consistency, Isolation and Durability") .

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

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

Физические ограничения

Firebird поддерживает большие базы данных. Базы данных могут быть расположены в нескольких файлах, предельный размер которых зависит от операционной системы. Теоретический предел в настоящее время составляет 64TB для одного файла базы данных, таким образом, главные ограничения накладываются файловой системой и местом на жестком диске.

Лицензирование

Firebird выпускается под условиями IPL(InterBase Public License) и IDPL (Initial Developer’s Public License), которые совпадают с условиями Mozilla Public License 1.1. Firebird полностью бесплатен для использования и распространения. Раскрытие исходного кода вашего продукта не требуется, вне зависимости от используемой модели лицензирования. Однако, в случае, если вы модифицировали исходный код сервера, то необходимо сделать доступным исходный код ваших модификаций.

Средства разработки и  администрирования

Для Firebird доступно большое количество инструментальных средств, бесплатных и коммерческих. Существуют средства разработки, средства администрирования, библиотеки внешних функций(UDF), средства доступа.

Поддержка

Компания IBPhoenix(В России, например компания iBase) предлагают профессиональную поддержку, выполняемую людьми с  многолетним опытом. На сайтах IBPhoenix и iBase.ru находится большое количество технической информации, инструкций и документации.

1.2 Проектирование базы данных предметной области «Учащиеся»

1.2.1 Концептуальное проектирование 

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

Предметная область информационной системы – это совокупность реальных объектов (сущностей), которые представляют интерес для пользователей.

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

Каждый объект характеризуется  рядом основных свойств – атрибутов. Атрибутом называется поименованная  характеристика объекта. Атрибут показывает, какая информация должна быть собрана  об объекте. Например, объект – клиент банка; Атрибуты – номер счета, адрес, сумма вклада.

Технология анализа предметной области.

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

Анализ предметной области  целесообразно разбить на три  фазы:

1. анализ концептуальных требований и информационных потребностей;
2. выявление информационных объектов и связей между ними;
3. построение концептуальной модели предметной области и проектирование концептуальной схемы базы данных.

1. Анализ концептуальных требований и информационных потребностей.

Требования пользователей  к разрабатываемой базе данных представляют собой список запросов с указанием  их интенсивности и объемом данных. Эти сведения разработчики базы данных получают в диалоге с ее будущими пользователями. Здесь же выясняются требования к вводу, обновлению и  корректировке информации. Требования пользователей уточняются и дополняются  при анализе имеющихся и перспективных  задач:

Анализ предметной области  БД для учета учащихся школы: 

1. Сколько учащихся учится в школе?
2. Сколько классов в школе?
3. Какие распределены учащиеся по тем или иным направлениям в классах?
4. Какие профилирующие дисциплины используются в том или ином классе?
5. Сколько в школе медалистов и какие?
6. Сколько победителей олимпиад и по каким предметам?
7. Участники тех или иных школьных, городских, областных, региональных или российских конкурсов? Победители, призеры?
8. Количество учащихся, поступивших в ВУЗ и в какие?
9. Как часто обновляется информация в БД?
10. Сколько кабинетов в школе? Компьютерных классов?
11. Сколько преподавателей в школе?
12. Как информация, представленная в п. п. 1-11, используется в настоящее время (расписание уроков, факультативов и т. д.) и как собираются ее использовать?
13. Сколько раз в день, сколько человек и кто используются БД?

2. Выявление информационных объектов и связей между ними.

Вторая фаза анализа предметной области состоит в выборе информационных объектов, задании необходимых свойств  для каждого объекта, выявление  связей между объектами, определении  ограничений, накладываемых на информационные объекты, типы связей между ними, характеристики информационных объектов.

Проанализируем предметную область на примере БД учета учащихся в школе. При выборе информационных объектов постараемся ответить на ряд  вопросов:

• На какие классы можно разбить данные, подлежащие хранению в БД?
• Какое имя можно присвоить каждому классу данных?
• Какие наиболее интересные характеристики (с точки зрения пользователя) каждого класса данных можно выделить?
• Какие имена можно присвоить выбранным наборам характеристик?

Для БД «Учащиеся» можно  описать следующие объекты:

Объект: УЧЕНИК

Атрибуты: ид_ученика, фамилия, имя, отчество, возраст, класс, фамилия, имя, отчество родителей, Серия и номер паспорта (свидетельства о рождении), какой язык изучает, участие в олимпиадах, различных конкурсах, призовые места.

Объект: УЧИТЕЛЯ:

Атрибуты: ид_учителя, ид_школы, фамилия, имя, отчество педагога, дата рождения, какой предмет преподает (ид_предмета), с какого года работает в школе, какое учебное заведение закончил, в каком году, категория, разряд, научное звание, год прохождения последней аттестации, год прохождения последних курсов повышения квалификации.

Объект: КЛАССНЫЙ РУКОВОДИТЕЛЬ

Атрибуты: ид_учителя, номер и параллель класса.

Объект: УСПЕВАЕМОСТЬ

Атрибуты: ид_успеваемость, ид_предмета, 1 четверть, 2 четверть, 1 полугодие, 3 четверть, 4 четверть, 2 полугодие, годовая, ид_ученика.

Объект: ПРЕДМЕТ

Атрибуты: ид_предмета, название предмета.

Объект: ШКОЛА

Атрибуты: ид_школы, название школы, директор, завуч, телефон.

Далее выясним связи между  информационными объектами. В ходе этого процесса постараемся ответить на следующие вопросы:

• Какие типы связей между информационными объектами?
• Какое имя можно присвоить каждому типу связей?
• Каковы возможные типы связей, которые могут быть использованы в последствии?
• Имеют ли смысл какие-нибудь комбинации типов связей?

Попытаемся задать ограничения  на объекты и их характеристики.

Под ограничением целостности обычно понимают логические ограничения, накладываемые на данные. Ограничения целостности – это такое свойство, которое мы задаем для некоторого информационного объекта или его характеристики и которое должно сохраняться для каждого их состояния.

Типы связей. Все информационные объекты предметной области связаны  между собой.

Соответствия, отношения, возникающие  между объектами предметной области, называются связями. Различаются связи  нескольких типов, для которых введены  следующие обозначения:

а) один к одному (1:1);

б) один ко многим (1:М);

в) многие ко многим (М:М).

Связь один к одному (1:1) предполагает, что в каждые момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

Рис. 1 иллюстрирует указанный тип отношений:

 
А1 
 
 
 
Рис. 1. Графическое изображение реального отношения 1:1

Примером связи 1:1 может  служить связь между информационными  объектами УЧИТЕЛЬ и КЛАССНЫЙ РУКОВОДИТЕЛЬ

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид, представленный на рис. 2.

Рис. 2. Графическое изображение реального отношения 1:М

Примером связи 1:М служит связь между информационными  объектами УЧЕНИК и УЧИТЕЛЬ

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот. На рис. 3 графически представлено указанное соответствие.

Рис. 3. Графическое изображение реального отношения М:М

Примером связи М:М  служит связь между информационными  объектами УЧИТЕЛЬ и КАБИНЕТ.

3. Построение концептуальной модели предметной области.

Заключительная фаза анализа  предметной области состоит в  проектировании ее информационной структуры  или концептуальной модели.

Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой  предметной области с учетом информационных интересов пользователей системы. Она дает возможность систематизировать  информационное содержание предметной области, позволяет как бы «подняться вверх» над программным обеспечением и увидеть ее отдельные элементы. При этом уровень детализации  зависит от выбранной модели.

Концептуальная модель является представлением точки зрения пользователя на предметную область и не зависит  ни от программного обеспечения СУБД, ни от технических решений.

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

Обычно для отображения  межфайловых связей используют диаграмму  Бахмана. 

1.2.2 Инфологическое проектирование

Инфологическая модель должна включать такое формализованное  описание предметной области, которое  легко будет "читаться" не только специалистами по базам данных.

Инфологическое проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД. Реляционная  модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области.

Проблема представления  семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую  модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность—связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность—связь", или "Entity Relationship", стала фактическим стандартом при инфологическом моделировании баз данных.

Модель «сущность-связь» называют также «ER-моделью» (essence-сущность, relation-связь).

ER-модели

Для основных элементов — сущностей, связей, атрибутов — в ER-моделях  используются следующие обозначения (надписи на всех рисунках будут  сделаны на этапе верстки):

Как правило, для именования сущностей  используют существительные, для связей — глаголы.

Если на этапе построения ER-модели определяются атрибуты, являющиеся первичными ключами соответствующих сущностей, то они, как правило, подчеркиваются.

Принадлежность атрибутов сущностям  и связи между сущностями обозначают линиями. Линии, обозначающие связи, снабжаются указаниями на тип связи (“один к  одному”, “один ко многим”, “многие  ко многим”). Единого стандарта на способ обозначения типа связи нет, в последнее время одним из наиболее удобных и наглядных  признан стиль, который используется в Microsoft Access. Согласно ему связи обозначаются цифрой 1 на стороне “одного” и символом “Ґ” на стороне “многих”.

Рассмотрим примеры из близкой  всем нам школьной жизни.

Сущность “ученик”

Атрибуты — уникальный (допустим — в пределах данной школы) номер, фамилия, имя, дата рождения.

Сущность “учитель”

Атрибуты — уникальный номер, фамилия, имя, отчество.

Сущность “предмет”

Атрибуты — уникальный номер, название.

Сущность “класс—ученик”

Тип — “один ко многим”.

Сущность “учитель—предмет”

Тип — “многие ко многим”.

Связи, как и сущности, могут  иметь атрибуты. Например, администрацию  школы нередко интересует стаж преподавания данным учителем данного предмета. Если подобную информацию необходимо хранить, то естественно добавить “стаж” в качестве атрибута связи “учитель—предмет”.

Переход от ER-модели к реляционной

Описанию реляционной модели данных посвящена отдельная статья (см. “Реляционные БД” 2).

При переходе от ER-модели к даталогической реляционной модели, как правило:

— каждая сущность описывается отдельной  таблицей;

— атрибуты становятся полями таблиц, для них задаются подходящие типы данных, имеющиеся в используемой СУБД;

— в таблицах определяются первичные  ключи, при необходимости вводятся суррогатные;

— для связей “многие ко многим”  вводятся соответствующие таблицы, снабженные, возможно, требуемыми атрибутами;

— при необходимости производится нормализация таблиц до заданной нормальной формы.

1.2.3 Реляционная модель БД

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

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

Реляционная БД представляет собой информацию об объекте, представленную в виде двумерного массива - таблицы  объеденных определен 
ными связями.

Выбор ключей.

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

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

Атрибут представляющие собой  копии ключей других отношений называется внешним ключом. Реляционная модель накладывает на внешние ключи  ограничения для обеспечения  целостности данных. Это означает, что к каждому значению внешнего ключа должны соответствовать строки в связываемых отношениях.

В разрабатываемой БД сущность табельный номер сотрудника будет  являться ключом для атрибутов сотрудники, отпуск, увольнение, командировка, трудовой договор и повышение квалификации (перевод).

Атрибут учащиеся так же имеет уникальные поля, такие как ИНН, серия и номер свидетельства о рождении, номер ученика, свидетельство о рождении не может являться ключом так как, вместо свидетельства о рождении  а ИНН может являться ключевым, но нам удобнее использовать как ключ номер ученика.

ГЛАВА 2. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ «УЧАЩИЕСЯ»

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

2.1 Анализ и выбор СУБД для разработки базы данных

Современная FireBird

Сейчас с уверенностью можно  говорить, что FireBird — развитое промышленное программное обес-печение, гарантирующее  транзакционную целостность данных при использовании его с множеством пользователей, соответствующее правилам ACID:

Atomicity — атомарность транзакций;

Consistency — целостность данных;

Isolation —изолированность  
(контроль доступа пользователей);

Durability — долговременность хранения данных.

Предназначенная для клиент-серверной  архитектуры, эта СУБД предъявляет  достаточно типичные требования при  выборе серверного оборудования для  серьезных проектов. А способность  отлично работать с большими базами и множеством клиентских подключений  давно успешно доказана как на выставках, так и в реальных коммерческих проектах. Тут действует универсальное правило — качество работы базы сильно зависит от того, кто ее проектировал.

В настоящее время можно насчитать  три стабильные современные ветви FireBird — это FB 2.0.x, FB 1.5.x. и вышедший во второй половине апреля 2008 г. релиз FB 2.1.

Уже в версии 1.5 все модули были аккуратно переписаны с учетом современных  стандартов языка C++. Версия 2.1 имеет  футурологическую направленность: в  нее успели заложить некоторые элементы, запланированные для архитектуры 3.0. В этой версии были добавлены  триггеры для общих событий базы данных, глобальные временные таблицы, выражение «UPDATE OR INSERT», использование  доменов для аргументов и переменных процедурного языка.

А вот «рабочей лошадкой» на апрель 2008 г. можно считать версию 2.0.x.

Конечно, применение СУБД FireBird очень  часто сопровождается использованием среды разработки Delphi, но она подойдет и не только для Delphi-разработчиков. Существуют бесплатно распространяемые драйверы для ODBC, Java, .NET (1.1, 2.0, 3.5), а также  библиотеки для низкоуровневого  доступа через C++.

FireBird предоставляет возможности,  стандартные для современных  промышленных СУБД: триггеры, просмотры,  хранимые процедуры, анонимные  блоки, функции, заданные пользователем,  домены, события, исключения, инкрементное резервное копирование данных. И при этом у «жар-птицы» остается отличительная черта — невысокие требования к аппаратным ресурсам и относительно простой процесс установки. Более того, в FireBird есть отдельный вариант сборки для встроенных однопользовательских решений (Embedded FireBird), работающий на одной-единственной библиотеке. Но при этом обеспечивается полная совместимость структуры базы для основного варианта использования этой СУБД.

2.2 Состав таблиц БД

Рассмотрим отношения  нашей БД подробнее.

Таблица 1«УЧЕНИКИ»