Создание базы данных

Лабораторная работа № 1: Создание базы данных

Цель работы: освоение приемов создания альяса и структуры баз данных, заполнения записями БД.

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

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

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

1       БД «Студенческая картотека ВКГУ»

Этап концептуального проектирования

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

Задачами данного этапа являются:

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

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

3.             Построение инфологической модели предметной области и документирования результатов анализа.

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

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

Предметная область при проектировании базы данных – Вуз

Подсистема – студенческая картотека.

Автоматизации подлежит задача хранения и компоновки данных о студентах.

Множество атрибутов предметной области представлены в таблице1.1

Таблица 1.1

Множество атрибутов предметной области

Характеристика ПО

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

Ограничения и допущения ПО

Относительно данной предметной области можно применить следующие допущения и ограничения:

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

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

3. Наличие льготы определяется:

А) первичной суммой оплаты

Б) результатами аттестаций летней и зимней сессий

Г) семейным положением

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

Построение ER-диаграммы ПО

Для разработки ER-диаграммы необходимо выделить объекты ПО и их атрибутивный состав. На основе перечня атрибутов выделим следующие сущности с атрибутами:

1.        Студент (ФИО, Дата, Нац, Адр, Билет)

2.        Специальность (Факул, Спец, Курс, Групп, Билет, Ном_дог)

3.        Оплата (Ном_дог, Форма_опл, Сумма, Льгот, Вид_льгот)

4.        Общежитие (Билет, Общеж, Срок_прож, Дата_въезд, Ном_ком)

Между полученными сущностями рассмотрим следующие связи:

1.    Студент – Специальность ® обучается

2.    Специальность – Оплата ® оплачивается

3.    Общежитие – Студент ® выделяется

В результате получим ER-диаграмму, изображенную на рисунке 1.1

Рисунок 1.1 – ER-диаграмма ПО

Этап логического проектирования

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

Выбор модели данных

Модель данных – это  форматы данных и состав операций, выполняемых над ними.

Существует иерархическая сетевая и реляционная модель данных.

Любая модель содержит 3 основных компонента:

1. структура данных – описывают точку зрения пользователя на представление данных.

2. набор допустимых операций, выполняемых на структуре данных.

3. ограничение целостности – механизм поддержания соответствия данных ПО на основе формально описанных данных.

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

Структура данных:

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

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

Ограничение целостности:

Здесь определены 2 базовых требования:

1 Целостность ссылок – сложные объекты представляются в РМД в виде картежей нескольких нормализованных отношений, которые связаны между собой. При этом связи между данными отношениями описываются в терминах функциональных зависимостей(ФЗ). Для отражения ФЗ между картежами разных отношений используется дублирование первичного ключа родительского отношения в дочернее. Атрибуты представляющие собой копии ключей родительских отношений наз. внешними ключами. Требования целостности по ссылкам состоит в следующем: для каждого значения каждого ключа появляющегося в дочернем отношении в родительском отношении должен найтись картеж с таким же значением первичного ключа.

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

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

1.    Студент

2.    Специальность

3.    Оплата

4.    Общежитие

Нормализация отношений

Нормализацией называется обратимый пошаговый процесс декомпозиции отношений на более мелкие с целью устранения нежелательных ФЗ.

ФЗ определяют семантические связи между атрибутами информации, понятие ФЗ распространяется на 2 и более атрибута. Если в любой момент времени каждому значению атрибута А соответствует не более чем 1 значение атрибута Б то говорят, что Б функционально зависит от А или А функционально определяет Б.

Полная ФЗ.

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

Транзитивная ФЗ.

ФЗ называется транзитивной если существует такой атрибут С что имеется ФЗ А®С и С®Б и соответствует ФЗ С®А.

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

Состав атрибутов отношения должен удовлетворять 2 основным требованиям:

1.             между атрибутами не должно быть нежелательных ФЗ.

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

Удовлетворение данных требований достигается нормализацией отношений.

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

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

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

1. Студент

2.              Специальность

3.              Оплата

4.              Общежитие

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

Реляционная модель данных имеет вид, представленный на рисунке1.2

Рисунок 1.2 – Реляционная модель данных

Задания:

1.      Изучив заданную тему выберите по варианту задание для самостоятельной работы (см. таблицу1.2)

2.      Разработайте этап концептуального проектирования выбранной базы данных

3.       Составьте описание предметной области: характеристика ПО, Ограничения и допущения ПО.

4.      Постройте ER-диаграммы ПО

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

Таблица 1.2