Студопедия.Орг Главная | Случайная страница | Контакты | Мы поможем в написании вашей работы!  
 

Защита курсового проекта



После полного завершения курсового проекта происходит защита курсового проекта.

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

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

Критериями оценки курсового проекта являются:

- степень разработки темы;

- полнота охвата научной литературы;

- творческий подход к написанию курсового проекта;

- правильность и научная обоснованность выводов;

- аккуратность и правильное оформление курсового проекта.

Окончательная оценка курсовой работы выставляется по итогам защиты и качеству работы.

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

Защищенные курсовые проекты студентам не возвращаются и хранятся в архиве учебного заведения.


8. Примеры предметных областей для написания курсового проекта

База данных «Фонотека»

Требуется создать базу данных фонотеки. В этой базе заказчик хотел бы хранить информацию

· о дисках, которые есть в этой фонотеке

· о том, к какому стилю относятся эти диски

· об исполнителях, чьи произведения записаны на этих дисках

· о клиентах, которые берут на прокат диски в этой фонотеке

Некоторые условия работы фонотеки, существенные для проектирования базы данных:

· в фонотеке может быть несколько различных дисков одного исполнителя

· бывают диски-сборники

· каждый клиент может взять в фонотеке несколько различных дисков

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

Этапы проектирования базы данных:

1. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных

2. определение атрибутов каждой сущности

3. выявление связей между сущностями

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

5. построение ER-диаграмм, отображающих выявленные связи

6. формирование таблиц базы данных по ER-диаграммам:

§ определение нужного количества таблиц

§ определение первичных и вторичных ключей таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

· выявленные объекты

· их атрибуты

· связи между объектами

· классы принадлежности (с обоснованием принятых решений)

· соответствующие ER-диаграммы

· описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1. создание описания таблиц (обычно в режиме конструктора)

2. создание схемы базы данных

3. создание форм, удобных для ввода данных в таблицу

4. создание кнопочной формы-заставки

5. заполнение таблиц (с использованием форм)

Форма отчета: показ на машине всех элементов созданной базы данных.

База данных «Турфирма»

Требуется создать базу данных для небольшой туристической фирмы. В этой базе заказчик хотел бы хранить информацию

· о странах, в которые фирма организует туры

· о наличии конкретных туров в данный момент

· о клиентах, обслуживаемых фирмой

Некоторые условия работы туристической фирмы, существенные для проектирования базы данных:

· каждый тур – в одну страну (но, конечно, может быть несколько различных туров в одну страну)

· на каждый клиент может заказать несколько туров (в одну или разные страны; для себя или для кого-то другого).

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

Этапы проектирования базы данных:

1. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных

2. определение атрибутов каждой сущности

3. выявление связей между объектами

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

5. построение ER-диаграмм, отображающих выявленные связи

6. формирование таблиц базы данных по ER-диаграммам:

§ определение нужного количества таблиц

§ определение первичных и вторичных ключей таблиц

§ определение атрибутов для всех таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

· выявленные объекты

· их атрибуты

· связи между объектами

· классы принадлежности (с обоснованием принятых решений)

· соответствующие ER-диаграммы

· описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1. создание описания таблиц (обычно в режиме конструктора)

6. создание схемы базы данных

7. создание форм, удобных для ввода данных в таблицу

8. создание кнопочной формы-заставки

9. заполнение таблиц (с использованием форм)

Форма отчета: показ на машине всех элементов созданной базы данных.

База данных «Строительное управление»

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

· о различных строительных специальностях

· об объектах, в строительстве которых участвует это управление

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

Некоторые условия работы строительного управления, существенные для проектирования базы данных:

· каждый строитель имеет несколько специальностей

· на одном объекте может работать много строителей

· в каждый конкретный момент каждый строитель работает на одном объекте.

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

Этапы проектирования базы данных:

1. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных

2. определение атрибутов каждой сущности

3. выявление связей между сущностями

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

5. построение ER-диаграмм, отображающих выявленные связи

6. формирование таблиц базы данных по ER-диаграммам:

§ определение нужного количества таблиц

§ определение первичных и вторичных ключей таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

· выявленные объекты

· их атрибуты

· связи между объектами

· классы принадлежности (с обоснованием принятых решений)

· соответствующие ER-диаграммы

· описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1. создание описания таблиц (обычно в режиме конструктора)

10. создание схемы базы данных

11. создание форм, удобных для ввода данных в таблицу

12. создание кнопочной формы-заставки

13. заполнение таблиц (с использованием форм)

Отчет: показ на машине всех элементов созданной базы данных.

Проектирование БД «Поставки деталей»

В этой базе заказчик хотел бы хранить информацию

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

· о характеристиках каждого поставляемого изделия (вес, металл, диаметр и т.п.)

· о поставщиках деталей

Некоторые условия, существенные для проектирования базы данных:

· каждый поставщик может поставлять несколько различных изделий

· одно и то же изделие может поставляться разными поставщиками

· возможна поставка одного и того же типа изделия, но с различными характеристиками.

Этапы проектирования базы данных:

1. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных

2. определение атрибутов каждой сущности

3. выявление связей между сущностями

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

5. построение ER-диаграмм, отображающих выявленные связи

6. формирование таблиц базы данных по ER-диаграммам:

§ определение нужного количества таблиц

§ определение первичных и вторичных ключей таблиц

1 и 2 этапы: объекты, их атрибуты и первичные ключи

Список объектов (сущностей): типы деталей, детали, поставщики

Сущности изображаются в виде прямоугольника, атрибуты вписываются внутрь прямоугольника, изображающего сущность:

           
     
 
 
 


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

           
   
   
 
 
 


3, 4 и 5 этапы: выявление степени связей и классов принадлежности, их фиксация с помощью диаграмм


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

 
 


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

6 этап: формирование таблиц базы данных по ER-диаграммам

В связи ТИПЫ ДЕТАЛЕЙ --- ДЕТАЛИ степень связи «один-ко-многим», n-связная сущность имеет обязательный класс принадлежности => в соответствии с ER-методом достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.

Но у нас в таблице ДЕТАЛИ уже есть такой атрибут – Название (он и будет вторичным ключом, соответствующим первичному ключу Наименование).





Дата публикования: 2015-04-06; Прочитано: 337 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!



studopedia.org - Студопедия.Орг - 2014-2024 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.012 с)...