Учебная работа. Реферат: Проектирование базы данных для отдела продаж автосалона методом нисходящего проектирования

Учебная работа. Реферат: Проектирование базы данных для отдела продаж автосалона методом нисходящего проектирования

Оглавление

Введение. 2

способ нисходящего проектирования. 2

ER-модель. 2

Даталогическая модель. 2

Физическая модель. 2

Типы данных. 2

SQL-запросы.. 2

Перечень литературы.. 2

Введение

Для разработки и проектирования систем БД употребляются разные средства моделирования. Конечной целью проектирования, разумеется, является БД. В теории проектирования ИС предметную область принято разглядывать в 3-х видах:

1) в том виде, в каком она реально существует

2) как ее принимает человек

3) как она быть может описана

процесс проектирования разбивается на три шага:

1) Концептуальное проектирование.
Собираются и анализируются данные. Редактируются требования к ним.
Для этого проводятся последующие мероприятия:

a) Обследование предметной области

b) Выявление всех фрагментов

c) Моделирование представлений

Опосля этого сделанных действий выходит мировозренческая модель, которая почаще всего представляется в виде «Суть-связь»

2) Логическое проектирование.
Преобразование требований к данным в структуры данных. В итоге получаем СУБД-ориентированную структуру БД.

3) Физическое моделирование.
На данном шаге определяются индивидуальности хранения данных, методов доступа и т.п.

способ нисходящего проектирования

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

В итоге выходит иерархическая схема, которая указывает состав и подчиненность отдельных функций. Эта схема также носит заглавие многофункциональной структуры метода приложения (ФСА).

При построении ФСА приложения нужно придерживаться последующей последовательности действий:

1. Найти цели автоматизации предметной области

2. Установить состав приложений, которые обеспечивают реализацию поставленных целей

3. Уточнить нрав связи приложений и их главные свойства

4. Найти нужные функции обработки данных

5. Выполнить декомпозицию функций до нужной структурной трудности

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

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

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

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

Главные понятия ER-диаграмм:

1) Суть – класс однотипных объектов информация о которых обязана быть учтена в моделях

2) Экземпляр сути – представитель сути

3) Атрибут сути — именованная черта, являющаяся неким свойством сути

4) Ключ сути – неизбыточный набор атрибутов, значения которых в совокупы являются неповторимыми для всякого экземпляра сути

5) Связь – некая ассоциация меж 2-мя сущностями
Делят три типа связей:

a) один-к-одному – экземпляр первой сути связан лишь с одним экземпляром 2-ой сути

b) один-ко-многим — экземпляр первой сути связан с несколькими экземплярами 2-ой сути. Суть со стороны «один» именуется родительской, а со стороны «много» — дочерней

c) много-ко-многим – любой экземпляр первой сути быть может связан с несколькими экземплярами иной сути. Является временным видом связи.

Любая связь владеет одной из 2-ух модальностей:

a) Может

b) Должен

В ER-диаграммах, как и в реляционных моделях БД существует понятие обычных форм.

1) 1-ая НФ – устраняются повторяющиеся атрибуты и группы атрибутов, т.е. выявление неявных сущностей.

2) 2-ая НФ – устраняются атрибуты зависящие от части неповторимого идентификатора. Таковая часть неповторимого идентификатора описывает отдельную суть

3) 3-я НФ – устраняются атрибуты, которые зависят от атрибутов не входящих в неповторимый идентификатор

Разглядим построение ER-диаграммы на примере выполняемой работы:

Представим предметную область как взаимодействие нескольких сущностей: «Спортсмен», «Тренер», «Вид спорта», «Соревнования», «Устроитель» и «Клуб». Суть «Клуб» и суть «Спортсмен» ведут взаимодействие средством связи «Состоит в». Связь имеет мощность «один-ко-многим» — т.е. один клуб может содержать у нескольких спортсменов. Для связи сущностей употребляется атрибут «Состоит в клубе». Дальше суть «Тренер» и суть «Клуб» ведет взаимодействие средством связи «Работает в». В данном случае мощность связи «один-ко-многим». Связь сущностей осуществляется через атрибут «Работает в». Суть «Тренер» и суть «Вид спорта» ведут взаимодействие средством связи «Обладает». Связь имеет мощность «один-к-одному», т.к. одна тренер может обладать (в данном контексте – тренировать) лишь одним видом спорта. Связь через атрибут «Тренирует по». Суть «Соревнование» «устраивается по» «Вид спорта». Связь этих сущностей имеет мощность «один-ко-многим», т.е. по одному и тому же виду спорта быть может устроено несколько соревнований. Суть «Устроитель» и суть «Соревнование» ведут взаимодействие средством связи «Спонсировать», где связь имеет мощность «многие-ко-многим», т.к. одно и то же соревнование могут спонсировать различные источники и в то же время источники могут спонсировать много соревнований. Суть «Устроитель» ведет взаимодействие с сутью «Спортсмен» средством связи «Вознаграждает» где мощность связи «многие-ко-многим», аналогично предшествующему. Суть «Клуб» и суть «Спортсмен» ведут взаимодействие средством связи «Выставляет на соревнование». Связь имеет мощность «один-ко-многому», т.к. один клуб может выставить на соревнование нескольких спортсменов. Суть «Тренер» и суть «Спортсмен» ведут взаимодействие средством связи «Тренирует». Связь имеет мощность «многие-ко почти всем», т.к. Спортсмен может иметь несколько тренеров, и тренер может иметь нескольких спортсменов. Суть «Спортсмен» и суть «Ссоревнование» ведут взаимодействие средством связи «Принимает участие от клуба». Связь имеет мощность «один-ко-многому».

Даталогическая модель

Модель предметной области обязана быть представлена в определениях модели определенной СУБД – в моем случае MS Access. Данная стадия носит заглавие логического моделирования БД. Результатом выполнения данной стадии является мировозренческая схема БД. Не все виды связей могут быть реализованы в логичекой модели. На данном шаге требуется конвертировать ER-диаграмму в реляционную схему.

1-ый шаг преобразования – перевоплощение каждой сути в таблицу (отношение). Каждое свойство становится столбцом таблицы.

2-ой шаг – преобразование связей во наружные ключи.

Опосля выполнения этих 2-ух шагов я получил последующую схему:

Физическая модель

Опосля получения концептуальной схемы можно перейти к созданию самой БД.

В данном случае БД представлена семью таблицами.

1) Клуб – 1 строчка – один клуб

2) Тренер – 1 строчка – один тренер

3) Вид спорта – 1 строчка – один вид спорта (заглавие)

4) Соревнование – 1 строчка – одно соревнование

5) Устроитель – 1 строчка – один устроитель

6) Стадионы – 1 строчка – один стадион

7) Спортсмен – 1 строчка – 1 спортсмен

Типы данных

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

Таблица Спортсмен

Столбец
Тип данных
Ограничение

ФИО
String[100]
NOT_NULL

Группа крови (внутренней средой организма человека и животных)
String[10]
NOT_NULL

Вес (кг)
Byte
NOT_NULL

Дата рождения
String[100]
NOT_NULL

Спортивное звание
String[100]
NOT_NULL

Вид спорта
String[100]
NOT_NULL

Состоит в клубе
String[100]
NOT_NULL

Тренится у
String[100]
NOT_NULL

Таблица Соревнование

Столбец
Тип данных
Ограничения

Вид спорта
String[100]
NOT_NULL

Дата проведения
Date
NOT_NULL

Устроитель
String[100]
NOT_NULL

Фаворит(и)
String[100]
NOT_NULL

пространство проведения
String[100]
NOT_NULL

Таблица Тренер

Столбец
Тип данных
Ограничения

ФИО
String[100]
NOT_NULL

Тренирует по
String[100]
NOT_NULL

Стаж
String[100]
NOT_NULL

Дата рождения
Date
NOT_NULL

Спортивное звание
String[100]
NOT_NULL

Работает в
String[100]
NOT_NULL

Таблица Устроитель

Столбец
Тип данных
Ограничения

ФИО / Заглавие организации
String[100]
NOT_NULL

Таблица Стадионы

Столбец
Тип данных
Ограничения

Заглавие
String[100]
NOT_NULL

Вместительность (чел)
Longint
NOT_NULL

адресок
String[150]
NOT_NULL

Таблица Вид спорта

Столбец
Тип данных
Ограничения

Заглавие
String[100]
NOT_NULL

Таблица Клуб

Столбец
Тип данных
Ограничения

Заглавие
String[100]
NOT_NULL

Стадион
String[100]
NOT_NULL



SQL
-запросы
Получить список стадионов, вмещающих не наиболее 30000 зрителей.

SELECT Стадионы.Заглавие, Стадионы.[Вместительность (чел)]

FROM Стадионы

WHERE [Вместительность (чел)] >= 30000;

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

SELECT Спортсмен.ФИО, Спортсмен.[Вид спорта]

FROM Спортсмен

WHERE [Вид спорта].Value=»Бокс»;

Получить перечень спортсменов, тренирующихся у данного тренера.

SELECT Спортсмен.ФИО, Спортсмен.[Тренируется у]

FROM Спортсмен

WHERE Спортсмен.[Тренируется у].Value=»Вакурин Е.Е.»;

Получить перечень тренеров обозначенного спортсмена.

SELECT Спортсмен.ФИО, Спортсмен.[Тренируется у]

FROM Спортсмен

WHERE Спортсмен.ФИО=»Родинов Г.К.»;

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

SELECT Соревнование.Устроитель, Соревнование.[Вид спорта]

FROM Соревнование

WHERE Соревнование.Устроитель=»Росспорт»;

Получить перечень призеров обозначенного соревнования.

SELECT Соревнование.[Вид спорта], Соревнование.[Победитель(и)]

FROM Соревнование

WHERE Соревнование.[Вид спорта]=»Шахматы»;

Получить перечень тренеров по определенному виду спорта.

SELECT Тренер.ФИО, Тренер.[Тренирует по]

FROM Тренер

WHERE Тренер.[Тренирует по] = «Бокс»;

Перечень литературы

1) Базы Данных – форум: ИНФРА-М, 2003 – 352с. Голицына О.Л., Максимов Н.В., Попов И.И.

2) ru.wikipedia.org

3) Базы данных. Учебник для вузов — Корона-принт, 2003 – 630с. Создатель: А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев

4) Базы данных – деньги и Статистика, 2003 – 592с. Диго С.М.

Спортсмен





Вид спорта





Соревнование





Устроитель





Клуб

]]>