Главная страница

Практическая работа 1. Проектирование базы данных


Скачать 2.91 Mb.
НазваниеПрактическая работа 1. Проектирование базы данных
Дата17.12.2022
Размер2.91 Mb.
Формат файлаpdf
Имя файлаbazy_dannykh._dlia_prakt_.pdf
ТипПрактическая работа
#849388
страница2 из 19
1   2   3   4   5   6   7   8   9   ...   19
Объект - ВИДЕОМАГНИТОФОН.
Атрибуты - страна-изготовитель, фирма-изготовитель, № модели, телевизионные системы, число кассетных гнезд, ресурс непрерывной работы, система автопоиска, напряжение в сети, наличие таймера, число программ, габаритные размеры, масса, цена в долларах, год выпуска.
Объект - ВИДЕОПЛЕЙЕР,
Атрибуты - страна-изготовитель, фирма-изготовитель, № модели, телевизионные системы, число воспроизводящих головок, ресурс непрерывной работы, напряжение в сети, наличие таймера, габаритные размеры, масса, цена в долларах, год выпуска.
Объект - ВИДЕОКАССЕТА.
Атрибуты - наименование, страна-изготовитель, фирма-изготовитель, тип кассеты, время проигрывания, цена в долларах.
Далее выделим связи между информационными объектами. В ходе этого процесса постараемся ответить на следующие вопросы:
1. Какие типы связей между информационными объектами?
2. Какое имя можно присвоить каждому типу связей?
3. Каковы возможные типы связей, которые могут быть использованы впоследствии?
4. Имеют ли смысл какие-нибудь комбинации типов связей?
Попытаемся задать ограничения на объекты и их характеристики.
Под ограничением целостности обычно понимают логические ограничения, накладываемые на данные. Ограничение целостности - это такое свойство, которое мы задаем для некоторого информационного объекта или его характеристики и которое должно сохраняться для каждого их состояния.
Введем следующие ограничения:
1.
Значение атрибута "число кассетных гнезд" изменяется от 1 до 2.
2.
Значение атрибута "ресурс непрерывной работы" изменяется от 4 до 24.
3.
Значение атрибута "напряжение в сети" изменяется от 110 до 240 В.
4.
Значение атрибута "число программ" изменяется от 1 до 20 и т.д.

11
Связи между различными классами объектов.
Помимо классов объектов в ИЛМ отображают связи между различными классами объектов. Такие связи моделируют отношения между объектами различных видов в реальном мире. При отборе связей помещаемых в ИЛМ следует руководствоваться информационными потребностями пользователей базы данных.
Каждая связь характеризуется именем, типом, классом принадлежности и направлением. Имя связи должно быть глагольным оборотом, например
«Принадлежит», «Закреплены за», «Входит в» и т.д.
Все информационные объекты предметной области связаны между собой.
Соответствия, отношения, возникающие между объектами предметной области, называются связями. Различаются связи нескольких типов, для которых введены следующие обозначения:
Различают четыре типа связи:
«один к одному» (1:1);
«один ко многим» (1:М);
«многие к одному» (М:1)
«многие ко многим» (М:М).
Рассмотрим эти типы связей на примерах.
Пример. Дана совокупность информационных объектов, отражающих учебный процесс в вузе:
СТУДЕНТ (Номер, Фамилия, Имя, Отчество, Пол, Дата рождения, Группа)
СЕССИЯ (Номер. Оценка 1, Оценка 2, Оценка 3, Оценка 4, Результат)
СТИПЕНДИЯ (Результат, Процент)
ПРЕПОДАВАТЕЛЬ (Код преподавателя, Фамилия, Имя, Отчество)
Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот. Рис. 8 иллюстрирует указанный тип отношений.
Рис. 8. Графическое изображение реального отношения 1:1
Примером связи 1:1 может служить связь между информационными объектами
СТУДЕНТ и СЕССИЯ:
СТУДЕНТ <-> СЕССИЯ
Каждый студент имеет определенный набор экзаменационных оценок в сессию.
При связи один ко многим (1 : М) одному экземпляру информационного объекта
А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид, представленный на рис. 9.

12
Рис. 9. Графическое изображение реального отношения 1:М
Примером связи 1: М служит связь между информационными объектами
СТИПЕНДИЯ и СЕССИЯ:
СТИПЕНДИЯ < -- >> СЕССИЯ
Установленный размер стипендии по результатам сдачи сессии может повторяться многократно для различных студентов.
Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот. На рис. 10 графически представлено указанное соответствие.
Рис. 10. Графическое изображение реального отношения М : М
Примером данного отношения служит связь между информационными объектами
СТУДЕНТ и ПРЕПОДАВАТЕЛЬ:
СТУДЕНТ <<—>>ПРЕПОДАВАТЕЛЬ
Один студент обучается у многих преподавателей, один преподаватель обучает многих студентов.
Связь «многие к одному» при создании БД физически обычно организуется путем введения дополнительного поля в таблицу со стороны «много». Это поле называется
внешний ключ. На рис. 10. код группы - внешний ключ.
Рис. 10. Введение внешнего ключа в БД
2.4. Построение инфологической (концептуальной модели) предметной
области
Заключительная фаза анализа предметной области состоит в проектировании ее инфологической структуры или концептуальной модели.
Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области (ПО) и выявляемых в результате анализа данных.
Концептуальная модель применяется для структурирования предметной области с учетом информационных интересов пользователей системы. Она дает возможность систематизировать информационное содержание предметной области, позволяет как бы

13
"подняться вверх" над ПО и увидеть ее отдельные элементы. При этом уровень детализации зависит от выбранной модели.
Концептуальная модель является представлением точки зрения пользователя на предметную область и не зависит ни от программного обеспечения СУБД, ни от технических решений.
Концептуальная модель должна быть стабильной. Могут меняться прикладные программы, обрабатывающие данные, может меняться организация их физического хранения, концептуальная модель остается неизменной или увеличивается с целью включения дополнительных данных.
Одной из распространенных моделей концептуальной схемы является модель
«сущность - связь» (ER-моделей (или ER-диаграмм)). Основными конструкциями данной модели являются сущности и связи.
Под сущностью понимают основное содержание объекта ПО, о котором собирают информацию. В качестве сущности могут выступать место, вещь, личность, явление.
Экземпляр сущности - конкретный объект.
Например:
сущность (объект) - служащий экземпляр сущности - Иванов А.В.; сущность (объект) - институт экземпляр сущности - МГУ.
Сущность принято определять атрибутами - поименованными характеристиками.
Например:
сущность - служащий атрибуты: ФИО, год рождения, адрес, образование и т.д.
Чтобы задать атрибут в модели, ему надо присвоить имя и определить область допустимых значений. Одно из назначении атрибута - идентифицировать сущность.
Связь определяет отношения между сущностями. Типы связей: один к одному,
один ко многим, многие ко многим.
При построении модели «сущность - связь» используют графические
диаграммы. При этом обозначают: сущности - прямоугольниками, атрибуты - овалами, связи - ромбами, см. рис.11.
На практике приходится строить нескольковариантов моделей, из которых выбирается одна, наиболее полно отображающая предметную область.
Классом объектовназывают совокупность объектов, обладающих одинаковым набором свойств. Например, для объектов класса «СТУДЕНТ» таким набором свойств являются: «ГОД_РОЖДЕНИЯ», «ПОЛ» и др.
Объекты могут быть реальными, как названный выше объект «СТУДЕНТ», и абстрактными, как, например, «ПРЕДМЕТЫ», которые изучают студенты.
Пример. Спроектировать БД "Сессия". База данных должна выдавать оперативную информацию об успеваемости студентов на факультетах в семестре. Результатами сессии считать только экзамены.
По сути дела и БД исходя из формулировки задания можно выделить лишь одно приложение. Речь идет об успеваемости студентов разных факультетов по тем или иным дисциплинам. Более конкретно речь идет о выдаче справок по результатам сессии каждого студента, учебной группы, курса, факультета, а также об автоматизированном составлении ведомости
Выберем следующие сущности:
ИНСТИТУТ,
ФАКУЛЬТЕТ,
СТУДЕНТ,
ПРЕПОДАВАТЕЛЬ,
ДИСЦИПЛИНА.

14
В данном примере можно выделить сущность ЭКЗАМЕН или ВЕДОМОСТЬ, но можно не выделять, а сформировать ведомость из имеющихся данных посредством связей.
Зададим каждую сущность набором атрибутов:
ИНСТИТУТ (название, подчиненность, адрес, телефон, ФИО ректора)
ФАКУЛЬТЕТ (название, код специальности, данные о кафедрах, число выпускников, декан).
СТУДЕНТ (ФИО, группа, курс, номер текущего семестра, пол).
ПРЕПОДАВАТЕЛЬ (ФИО, должность, звание, кафедра, стаж).
ДИСЦИПЛИНА (название, число часов, код дисциплины, виды занятий, число читаемых семестров, номера текущих семестров, на каких курсах преподается)
В каждом наборе атрибутов, характеризующих сущность, необходимо выбрать ключевые атрибуты, т.е. атрибуты, делающие сущность уникальной. При задании атрибутов ключевые атрибуты подчеркивались.
Определим связи между сущностями.
Название связи
Связи между сущностями учится студент, факультет изучает студент, дисциплина имеет институт, факультет работает преподаватель, факультет преподает преподаватель, дисциплина экзамен студент, дисциплина, преподаватель
После выбора сущностей, задания атрибутов и анализа связей можно перейти к проектированию информационной (концептуальной) схемы БД.
Концептуальная схема БД "Успеваемость» представлена на рис.11 (атрибуты сущностей на диаграмме не показаны).
Рассмотрим некоторые ограничения в рассматриваемом примере:
1 Значение атрибута "телефон" (сущность - ИНСТИТУТ) задается целым положительным шестизначным числом.
2 Значение атрибута "код факультета" (сущность - ФАКУЛЬТЕТ) лежит в интервале 1-10.
3. Значение атрибута "курс" (сущность - СТУДЕНТ) лежит в интервале 1 - 6 4. Значение атрибута "семестр" (сущность - СТУДЕНТ, ДИСЦИПЛИНА) лежит в интервале 1-12.
5. Значение атрибута "число часов" (сущность - ДИСЦИПЛИНА) лежит в интервале 1-300.
6. Одному студенту может быть приписана только одна группа.
7. Один студент может учиться только на одном факультете.
8. Один студент в семестре сдает от 3 до 5 дисциплин
9. Один студент изучает в семестре от 6 до 12 дисциплин.
10.
Одному преподавателю приписывается только одна кафедра.
11.
Один студент может пересдавать одну дисциплину не более трех раз.
12.
Ключи: название института, название факультета, ФИО и группа студента,
ФИО и кафедра преподавателя, название дисциплины.

15
Рис 11. Концептуальная схема БД «Успеваемость»
Рис. 12. Пример построения инфологической модели данных.
3. ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
3.1.
Даталогическое проектирование
Инфологическая модель является исходной для построения даталогической модели
БД и служит промежуточной моделью для специалистов предметной области (для которой создается банк данных (БнД)) и администратора БД в процессе проектирования и разработки конкретной БД.

16
Рис. 13. Структура проектирования БД
Под даталогической понимается модель, отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физической организации.
При этом даталогическаямодель разрабатывается с учетом конкретной реализации
СУБД, также с учетом специфики конкретной предметной области на основе ее инфологической модели.
Инфологическая модель предметной области строится первой. Предварительная инфологическая модель строится еще на предпроектной стадии и затем уточняется на более поздних стадиях проектирования баз данных. Затем на ее основе строятся концептуальная (логическая), внутренняя (физическая) и внешняя модели.
Конечным результатом даталогического проектирования является описание логической структуры базы данных на языке программирования. Однако если проектирование выполняется «вручную», то для большей наглядности сначала строится схематическое графическое изображение структуры базы данных. При этом должно быть обеспечено однозначное соответствие между конструкциями языка описания данных и графическими обозначениями информационных единиц и связей между ними.
Графическое представление используется и при автоматизированном проектировании структуры базы данных как интерфейсное средство общения с проектировщиком, и при документировании проекта.
Спроектировать логическую структуру базы данных означает определить все информационные единицы и связи между ними, задать их имена; если для информационных единиц возможно использование разных типов, то определить их тип.
Следует также задать некоторые количественные характеристики, например, длину поля.
3.2.
Описание датологической модели.
Даталогическая модель представляет собой описание базы данных, выполненное в терминах используемой СУБД. Наиболее часто при разработках баз данных применяют реляционные СУБД. Для СУБД этого типа даталогическая удобно представить в виде набора таблиц специальной формы (табл. 1.4.).
Такая таблица составляется для каждого отношения, используемого в базе банных.
Отношения в базе соответствуют классам объектов из инфологической модели. Кроме того, отношения могут представлять некоторые связи предметной области.
Каждой таблице нужно поставить в соответствие ее ключи. Схема ключа представляет собой перечисление атрибутов отношения, составляющих ключ.
Различают простые и составные ключи. Простой ключ строится на основе одного атрибута. Составной ключ строится на базе использования нескольких атрибутов.
Ключи принято разделять на первичные, внешние и вспомогательные.
Первичный индекс должен быть только один для каждой таблицы. Значения атрибутов, используемых для формирования первичного ключа, должны быть

17 уникальными для каждой записи в таблице. Значения первичного ключа уникально идентифицируют каждую запись. Не может быть двух записей в таблице с одинаковым значением первичного ключа. Например, в качестве первичного ключа для отношения
«Сотрудники» можно выбрать атрибут «Табельный номер», значение которого является уникальным для каждой записи о сотруднике.
Внешние ключи используются для реализации связей типа 1:М между отношениями. Внешний ключ строится для отношения, находящегося на стороне
«много» связи 1:М. Для каждого такого отношения на даталогической модели должен быть показан внешний ключ. Внешний ключ всегда должен иметь соответствующий ему первичный ключ отношения, находящегося на стороне «один» связи типа 1:М.
Для связанных ключа «внешний - первичный» соединяются на схеме даталогической модели ломаной линией. Например, если в таблице «Сотрудники» имеется атрибут
«Шифр категории», то этот атрибут можно использовать в качестве внешнего ключа для связи с таблицей «Категории». В последней таблице должен быть первичный ключ по полю «Шифр категории». Внешних ключей может быть несколько для одной таблицы.
Следует отметить, что первичные и внешние ключи строятся как правило на основе целочисленных атрибутов, а не атрибутов, имеющих строковый или вещественный тип.
Кроме первичных и внешних ключей часто используют вспомогательные индексы.
Они применяются для реализации связей, получения нужного упорядочения при выводе на экран и создании отчетов и т.д. В каждом случае использования вспомогательного индекса, его необходимость должна быть обоснована. Применение большого количества индексов замедляет работу СУБД, т.к. операции над записями отношения требуют корректировки всех индексов.
II. ЗАДАНИЕ ВЫПОЛНЕНИЯ ПРАКТИЧЕСКОЙ РАБОТЫ
Практическая работа №1 выполняется письменно и в конце занятия сдается на
проверку. После проверки будет выставлена оценка.
2.1.
Выбор задания
Выбрать из таблицы «Варианты заданий для лаб.работы №1.doc» вариант задания, соответствующий номеру студента в списке учебной группы. Для всех последующих практических работ вариант остается неизменным. Каждому студенту предоставляется свой вариант предметной области (ПО), который он будет использовать в процессе выполнения всех практических работ.
2.2.
Анализ предметной области.
На основании выбранного варианта привести: название предприятия, цель деятельности предприятия, структура предприятия, информационные потребностей пользователей (кратко).
2.3.
Описание основных сущностей ПО.
Здесь следует привести описание основных сущностей (объектов) ПО. Отбор сущностей производится на основе анализа информационных потребностей. Необходимо привести таблицы описания сущностей (сущностей должно быть не менее 3-х)
Таблица 1.1. Список сущностей предметной области.
N п.п.
Наименование сущности
Краткое описание
Здесь же приводится отбор атрибутов (не менее 5-ти) для каждого экземпляра сущности. Отбираются только те атрибуты сущностей, которые необходимы для формирования ответов на регламентированные и непредусмотренные запросы. Для каждого объекта следует привести таблицы его атрибутов.

18
Таблица 1.2. Список атрибутов.
N п.п.
Наименование атрибута
Краткое описание
На основе анализа информационных запросов следует выявить связи между сущностями. Для выявленных связей также нужно заполнить таблицу 1.3.
Таблица 1.3. Список связей ПО.
N п.п.
Наименование связи
Сущности, участвующие в связи
Краткое описание
2.4.
Построение инфологической модели.
На основании ранее выбранного варианта и таблиц 1.1-1.3:

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

расставить существующие связи между ними,

на основании табл. 1.3. в письменной форме обосновать типы связей (1:1,
1:М и т.д.).
При графическом построении ИЛМ следует придерживаться единого масштаба для всей схемы. Все прямоугольники, обозначающие классы объектов, должны быть одного размера. Аналогично, все ромбы с именами связей также должны иметь одинаковый размер.
1   2   3   4   5   6   7   8   9   ...   19


написать администратору сайта